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I. INTRODUCTION 


Adaptive Architectures for Command and Control (A2C2) is a research program 
sponsored by the Office of Naval Research, made up of a number of teams from firms, 
defense laboratories and universities including Naval Postgraduate School. They have 
been collaborating to address issues concerning innovative and adaptive organizations. 
The main tool used in A2C2 Experiment is known as the Distributed Dynamic 
Decision-making (DDD) simulation system. This is a distributed multi-person wargaming 
simulator used for understanding how high-performance teams operate in complex 
environments. Different from other wargaming simulators, the DDD has a unique 
flexibility being able to capture the essential elements of different team tasks, to allow the 
experimenter to vary team stmcture, access to information, and control of resources. The 
analytical models and the experimentation tools - most notably the Distributed Dynamic 
Decision-making (DDD) simulator (Kleinman, 1996) - have undergone considerable 
refinement, improvement, and extension in order to deal with the increasing complexity 
of relevant C2 issues. More details about the DDD follow in chapter two. 

Results from C2 experiments have shown that ""the better an organization is 
matched structurally to the overall mission, the better will that organization perform - 
and that mismatches are potential drivers for adaptation of organization structure ” This 
is described in organization theory as the concept of “organizational congmence”. 


The most recent A2C2 Experiment (8), aimed especially to establish the 
experimental conditions in which the relationship between congmence and performance 
could be tested (Kleinman et ah, 2003). 


The basic approach of A2C2 Experiment 8 was to define two disparate 
organizational stmctures and then design two missions (scenarios) that exploited the 
differences between two stmctures. Then, the next step (Diedrich et ah, 2003) was to 
contrast performance under conditions in which organizational stmctures and missions 
were congment with performance under conditions in which they were incongment. 
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The results of Experiment 8 (Kleinman et al., 2003), clearly show that 
performance in the congruent cases (fit between organization and mission) was 
significantly higher when compared with incongruent cases (misfit between organization 
and mission). Performance in this experiment was defined broadly in terms of the number 
and percentage of tasks completed. Various other measures of performance have been 
recorded to develop a better understanding of the subject. 

In parallel, but without a direct link to the A2C2 research stream, the Virtual 
Design Team (VDT) research was initiated in the late 1980s at Stanford University, with 
the goal of “developing new micro-organization theory and embedding it in software 
tools that could be used to design organizations” . The VDT research (Fridsma, 2003; 
Salazar-Kish, 2001; Fridsma, 2000; Fambert, 2000; Mahalingam, 2000; Kunz et al, 1998; 
Thomsen, 1998; Jin and Fevitt, 1996; Fevitt et al, 1994; Christiansen, 1993; Cohen, 

1992) aimed to operationalize and extend Galbraith's information-processing framework 
to model and simulate project organizations. Over the past ten years, the VDT research 
group has built upon the original framework and developed confidence in the predictions 
of their theory and tools, which eventually led to the development of SimVision™ - a 
commercial adaptation of the VDT model. 

The primary challenge of this project was to take the VDT out of its commercial 
use and explore its potential for modeling organizational parameters in a military context. 
To date, VDT has been used principally in the domain of project management. 

Attempting to adapt this research approach and toolset to military command and control 
represents a challenging problem. 

Our primary goal in this project is to determine if and how we could use VDT to 
emulate the results obtained from A2C2 Experiment 8. Building on previous work of 
both A2C2 and VDT research teams, we also intend to keep records of the various 
models and behaviors we develop in order to assist people in the future who may want to 
expand on our work. 


2 



Before beginning our analysis we focused on learning the basics of DDD and 
VDT simulation techniques and on how the models used in DDD can be analyzed with 
VDT. To understand how DDD really works, we took part as players/decision makers 
within the ongoing experiments held in the lab. We played several mission scenarios that 
were either matched (congruent) or mismatched (incongruent) with two organizational 
structures (Functional, Divisional). We were surprised to see how flexible and user- 
friendly was the DDD, and “we felt on our own” how performance is reduced in 
incongruent scenarios. Concurrently we became familiar with the VDT software through 
VDT tutorials. The four major phases involved in our project are shown graphically in 
Figure 1.1. 


RESEARCH METHODOLOGY: 


Analyze the DDD _^ Map the _^ Model the scenario _^ Simulate, Analyze & 

context/scenario variables using VDT Interpret results 


Organization^ 
structure 



Assets/ 

Capabilities 









Figure 1.1 - The four phases of our team project. 


In the first phase, we identified what we considered to be major contexts affecting 
the congruence/incongruence between organizational structure and mission, using the 
scenarios and the concluding results from the most recent A2C2 experiment (Experiment 
8 ). 
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In the second phase, we attempted to map the relevant variables finding the 
“appropriate match” between DDD and VDT parameters (organization structure, 
missions, assets/capabilities, tasks etc.). We identified simple but relevant DDD 
“behaviors” (e.g., resource performing task, contention for resources, delay in resource 
availability, resource expended, task decomposition, coordination), aiming to replicate 
them with VDT. 

In the third phase we began the modeling process. We started to incorporate DDD 
contextual behaviors and their local effects into the existing VDT structure. We 
replicated the identified DDD behaviors and successively refined the VDT models until 
we got an acceptable match with DDD behaviors. Also in the third phase we started to 
model with VDT the DDD scenarios: a functional scenario (f) that fits the functional 
organization (F), while being misfit to the divisional organization (D), and a divisional 
scenario (d) that fits D but not F. A fuller description of all these efforts is given in 
Chapters IV and V. 

The initial plan for the final phase was to use VDT simulation capabilities for 
testing and refining VDT models. We also planned to analyze and compare the results 
against the observed organizational performance during A2C2 Experiments. 

This last goal was not reached due to the challenges of modeling critical DDD 
behaviors with VDT. As a consequence, we limited our work on the final phase to 
analyzing and interpreting the VDT simulated results and to documenting the gains and 
limitations of our work, to assist people pursuing this topic in the future and to provide 
more in-depth examination of how VDT can be used as a pre-experimental modeling tool 
for A2C2 research. The iterative process established between phase 3 and 4 allow us to 
analyze results and further refine the VDT models. 

In this chapter we have highlighted the starting points, the research goals and the 
sequence we followed to achieve these goals. The primary goal for this project is to 
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explore the viability of a eomputational model designed for program management to 
validate military-speeifie seenarios and organizations. 

In Chapters II and III we review the relevant faets about DDD and VDT, both as a 
neeessary step to Chapter IV and also eontributing to a better understanding of the two 
approaehes to modeling and simulation. In Chapter IV we illustrate our efforts to 
understand the similarities and differenees between DDD and VDT. This is a neeessary 
step for ineorporating the basie DDD behaviors into the VDT simulation model. In 
Chapter V we deseribe in detail the work of building VDT models based on DDD 
seenarios, ineluding detailed explanations of various models and behaviors. Finally, we 
eonelude by highlighting the eontributions of this work, some limitations of the projeet, 
and the major eonelusions of these modeling experiments. 
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II. DDD AND A2C2 EXPERIMENT 8 


This chapter presents the salient behaviors of DDD that are relevant to our 
modeling proeess. All the material for this seetion is taken from the following sources: 
Diedrieh et al, “Adaptive Arehitectures for Command and Control: Toward an Empirieal 
Evaluation of Congruence and Adaptation,” 2002; Kleinman et al, “Scenario Design for 
the Empirical Testing of Organizational Congruence,” 2003; Diedrieh et al, “When Do 
Organizations Need to Change (Part I) Coping with Ineongruence,” 2003 and David E. 
Kleinman presentation “The DDD. A Team-In-The-Eoop Software Tool for Performance 
Evaluation of Distributed Organizations,” 2001. 


A, THE DDD PERSPECTIVE 

The DDD is a distributed real-time simulation environment that allows empirical 
study of team deeision making within eomplex situations. Humans make deeisions based 
on information and resourees provided via a simulated framework, and internet in real¬ 
time with other distributed team members. The DDD enables the manipulation of 
variables sueh as organizational structure and mission seenario within a eontrolled 
laboratory environment. The ways in whieh deeision makers (DMs) within a given 
organization coordinate their information, resourees and activities to attain common goals 
in a dynamic and uncertain task environment has been the focus of A2C2 research for the 
past ten years. 

The first step in the researeh proeess abstracts real world problems into a 
controlled laboratory environment where DMs “play” in the DDD simulation with the 
team structure (organization) and task environment (seenario) defined by the experiment 
designer. A variety of performance measures (dependent variables) are reeorded such as 
tasks processed, latencies, and accuracies that allow us to examine the interaetions 
between task or mission structure and the way in whieh the organization responds to 
mission requirements. Eigure 2.1 displays the elements involved in team deeision 
making. 
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Figure 2.1 - Empirical (laboratory) research in team decision making. 

B, ENVIRONMENT 

The need to perform efficiently in a Joint battle space led to the design of a DDD 
paradigm that includes a variety of task classes (e.g., mines, surface threats, strike) and 
controllable platforms with sub platforms, sensors and weapons (resources) across air, 
sea and ground. The Joint warfare concept was used to frame the DDD paradigm, with a 
Joint Task Force (JTF) commander and subordinate DMs, each having responsibility for 
different but overlapping elements in a common battle space. Under this scenario subjects 
are required to follow a predefined mission thread (“task graph”), while at the same time 
defending one or more “penetration zones”, and of course their own assets, against 
potential threats (ground, sea and air). DDD has the ability of to constrain and/or to 
manipulate organizational structures such as authority, information, communication, 
resource ownership, task assignment, creates dynamic capabilities for decision making 
and coordination processes. The overall mission objective must be accomplished through 
coordination among the DMs in such a manner that allocation of limited organic and non- 
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organic resources are matehed to the requirements of a set of interacting tasks. 


C. MISSION STRUCTURE - TASK DIMENSIONS 


The scenario designer can create a template of “tasks”, with defined attributes, 
threat capabilities and movements that are linked together by time, spaee and preeedenee 
to provide a theater level mission for the organization to aecomplish. An example of a 



Figure 2.2 - Mission task graph. 


Primarily, Figure 2.2 illustrates the task proeessing sequence. The mission tasks 
shown as eireles are the tasks that must be done and are “known” in advance. This 
preeedenee strueture indieates the eourse of aetion that the players must follow. For 
example, the enemy command center (CMD) must be destroyed before the eapture of the 
Naval Base East (NBE). In addition, some tasks have prerequisites. Eor example, mines 
must be cleared before the NBE and Port tasks can be performed. Also there are ongoing 
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tasks initiated from the start ineluding defend tasks (e.g., self defense) or eneounter tasks 
(e.g., clear SAMs, destroy enemy ground forces). 

The characteristics of each task are: type, class, attributes and resources required. 
Tasks are categorized by type as: air, sea, or ground and are further divided into a variety 
of classes such as minefields, SAM sites, etc. Attributes are a set of characteristics that 
define the task and could include speed, hostility, IFF status, etc. Each task has an 
associated “resource vector” that defines the resources required to successfully process 
that task. These predefined resources (generic task requirements) are selected by the 
experiment designer depending on the simulated level of aggregation of the problem. 

D, PLATFORMS 

Platforms are high value assets that carry sensors and resources (e.g., ships, 
forward operating bases). The “owner” of a platform controls that platform, and can 
reposition it geographically and command it to attack. Platforms are also categorized by 
type and by class. 

A platform will often carry sub platforms (e.g., a carrier can contain helicopters 
and aircrafts) and weapons systems. A sub platform is available for use for a limited time 
period and could be categorized as either returnable (helicopters), or non-returnable 
(sonobuoys). Also, sub platforms can be designated as reusable (multiple attacks) or non- 
reusable (one attack). In both cases (returnable and reusable) there is a time-window that 
defines a sub platform’s availability. 

A sub platform (e.g., a fixed-wing aircraft, helicopter, UAV, SOF team) is 
“launched” from its parent platform, maneuvered to its objective, but has a finite time 
duration and weapon load (number of “shots”) before having to return for refuel or 
reload. The weapons on a platform (e.g., surface-to-air missiles) are “fire and forget” but 
are limited in number. The breakdown of resources (platforms, sub platforms and 
weapons) used in A2C2 Experiment 8 is shown in Eigure 2.3. 
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fixed platforms 

mi/min 

loadout (subplatforms and weapons) 

DDGA 

Aegis-capable destroyer 

0 

6SM2, 2HARP, 8TLAM, 4TTOM, 3ABM, 1FAB, 1HH60, 1UAV 

DDGB 

Aegis-capable destroyer 

0 

6SM2, 2HARP, 8TLAM, 4TTOM, 3ABM, 1FAB, 1HH60, 1UAV 

DDGC 

Aegis-capable destroyer 

0 

6SM2, 2HARP, 8TLAM, 4TTOM, 3ABM, 1FAB, 1HH60, 1UAV 

FFG 

Aegis-capable frigate 

0 

4SM2, 2HARP, 


1MH53, 1FAB, 1HH60, 1UAV 

CG 

Aegis-capable cruiser 

0 

6SM2, 2HARP, 8TLAM, 3ABM, 1MH53, 1FAB, 1HH60, 1UAV 

CVN 

Aircraft carrier 

0 

2F18A, 2F18S, 


1MH53, 1FAB, 1HH60, 1UAV 

E2C 

AW ACS - aircraft 

0 

sensors only - prepositioned for total air surveillance in AOR 

FOB 

forward operating base 

0 

3SOF teams preinserted in Country A 



AOF 

air ops facility on Island E 

0 

2F18A,2F18S 





subplatforms (reloadable) 

mi/min 

Tavail 

# shots 


weapons 

mi/sec 

range 

F18A 

air-to-air defender 

200 

15min 

2 


SM2 standard surface- 

5.0 

lOOmi 







air missile 



F18S 

air-to-ground strike aircraft 

200 

15min 

1 


ABM anti-ballistic missile 

7.0 

85mi 

MH53 

helicopter mine clearer 

40 

60min 

2 


TEAM Tomahawk cruise 
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360mi 







missile 



HH60 

search and rescue helo 

45 

18min 

1 


TTCM tactical/steerable 

2.0 

500mi 







Tomahawk 



UAV 

unmanned recon vehicle 

30 

60min 

n/a 


FIARP Flarpoon anti-ship 

1.5 

60mi 


sensor only 





missile 



FAB 

fast attack boat 

25 

20min 

2 





SOF 

special ops/SEAL team 

40 

60min 

GO 






Figure 2.3 - Platforms, Sub platforms and Weapons 


Some of the other information in Figure 2.3 includes the velocity of the sub 
platforms (mi/min), their endurance or available time, and the numbers of “shots” each 
can take before needing to return to its parent for reload. The number of shots is 
equivalent to the number of tasks that a sub platform can process/attack with a full 
payload. The velocities are approximately ten times real-world values as the game is 
played at a 10:1 time scale. Some additional information not shown in Figure 2.3 include 
the sub platform launch and weapon firing delay, and the duty cycle time between 
successive launches/firings. 


Asset (platforms, sub platforms, weapons) capabilities are defined by the resource 
vector which has the same elements as those associated with the task processing 
requirements. The total capabilities of an asset package (one or more assets) that is 
assigned to attack a task must be equal to or exceed the task requirements in order for the 
attack to be characterized as successful, otherwise the attack will achieve only partial 
success. A combination of the synchronicity and correctness of the allocated assets is a 
measure of the effectiveness of the attack. 
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E, MEASURES AND DATA COLLECTION 

A variety of dependent variables are eolleeted by the DDD software that are 
amenable to study and evaluate different task and organizational struetures. Performanee 
measures and proeess measures are the two basie eategories, not neeessarily independent, 
that ean be used to tabulate the performanee during the experiment. 

Performanee measures deal with team score and mission effectiveness. These 
include: team timeliness measures such as latency and slack time; team performance 
quality includes measures such as accuracy and efficiency in either information 
processing or resource allocation. In the same manner process measures describe the 
mechanisms by which the team attained its performance. These measures include the 
distribution of load between DMs, resource utilizations, as well as communication 
patterns among DMs. 

F. DDD AND A2C2 

In recent experiments the DDD was used as an empirical tool to examine the 
concept of organizational “congruence.” The approach for testing the congruence 
theories was to define two disparate organizational structures and design two missions 
(scenarios) that exploit the differences in these two structures. 

The first mission-scenario was “tuned” (high degree of congruence) to 
organization 1 and was “mismatched” (i.e., low congruence) with organization 2. The 
opposite was implemented for the second scenario. The two organizational structures 
selected for experimentation are commonly referred to as Functional (F) and Divisional 
(D). In the Functional organization structure, each participant is specialized in one aspect 
of the mission (such as Strike) using assets that are distributed across multiple platforms 
(ships). In the Divisional structure, each participant has control over a multifunctional 
platform and can perform a variety of tasks in a localized geographical region. Thus, a 
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particular mission scenario favored either a divisional or a functional architecture, and 
was mismatched to the other architeeture. 

A2C2 experiment number eight (E8) was eonducted at NFS in August and 
November 2002. Partieipants engaged in a simulation of a mission involving six 
geographieally dispersed eommanders in eontrol of assets including six major platforms: 
three destroyers (DDGA, DDGB, and DDGC), a frigate (FFG), eruiser (CG) and aircraft 
carrier (CVN) and the related sub platforms and weapons. 

The military eontext for F8 was that country A has invaded and oeeupied friendly 
eountry B and has seized eountry B’s major port (PORT). If attacked, eountry A has 
threatened to use tactical ballistic (SCUD) missiles against US allies, island eountries D 
and E. She has also threatened to mine the sea-lanes in order to shut down merehant 
traffie. Country C eould align with eountry A in opposing US military aetions. Enemy 
forees are eoneentrated around A’s naval bases (NBE, NBW) and air bases (ABE, ABW), 
and are proteeting a major bridge (BR). The enemy has an integrated air defense system 
(aireraft and surfaee-to-air missiles), and has surfaee eapability (fast patrol boats and 
missile-firing destroyers). In addition they have plaeed their eoastal defense missiles in 
positions that give them maximum standoff against U.S. Navy ships. The military eontext 
is illustrated in Figure 2.4. 

Joint Task Foree objeetives are to establish air and sea dominanee in the Area of 
Responsibility (AOR), to prepare the battle spaee for the introduetion of follow-on 
ground forees, to proteet the allies in the region from SCUD missiles, and to proteet itself 
(and neutral shipping) from enemy air and sea attaek. 
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Figure 2.4 - Experiment 8 scenario. Area of Responsibility (AOR). 

Figure 2.4 shows the fixed location of the six major JTF assets plus an Air 
Operations Facility (AOF) on Island E and a Forward Operating Base (FOB) in Country 
A. Both scenarios have been based on the same task graph, with the salient differences 
being only in the individual task requirements and enemy force dispositions. To test the 
hypothesis that congruence between organization and mission leads to good performance, 
two scenarios were constructed, as shown in Figure 2.5. The first scenario (f) is 
congruent with organization F and incongruent to organization D while the second 
scenario (d) is congruent with organization D but misfit to organization F. Of note in 
Figure 2.5 is that while the tasks (indicated by circles) are the same in both scenarios, the 
asset requirements for accomplishing the tasks vary. It is this variation that defines the fit 
or misfit of the two structures with the two scenarios. 
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TASK GRAPH - A2C2 EXPERIMENT 8 - Scenario f 


Defend 
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to SOF 
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2SOF+2FAB 


' indicates that these must be distinguished from neutral (or decoy) counterparts 


TASK RESOURCE REQMTS 

SDG: 2ASuW 
SPT, SPH: 1 ASuW 
SGUN: 2 FAB 
SSAR: 2SAR 
SMIN: 2 MINES 

GEVA: 2SAR 

GCDL, GSML: 1 STRK 

GSAM: 2 TLAM (from 2 different platforms) 

GSA3:2STRK(1 F18S) 

GSA6: 2 TLAM (from 2 different platforms) 
GRGF: 3 STRK 

AAC, APH, ACDM, AXOC: 1 AAW 
ACAP: 3AAW 
AMIS: 1 ABM 

- other unanticipated tasks via HELP 


TASK GRAPH - A2C2 EXPERIMENT 8 - Scenario d 


Defend 
own assets 

•ACDM \ 
• Air(AC, PH‘) 
•Sea(PB, PH‘) 
•Sea(DG) / 


Obstacles 
to SOF 


1 MD\Ar 1 

1 k. 

• CAP/AC 
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1 ► 
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ABW^^ 


1MINE+1F18A 



Obstacles 
to SOF 



TASK RESOURCE REQMTS 

SDG: 1 ASuW+ 1 AAW 
SPT, SPH: 1 ASuW 
SHOS: 1 SAR + 1 FAB 
SSAR: 1 SAR + 1 FAB 
SMIN: 1 MINES + 1 F18A 

GEVA: 1 SAR + 1 F18A 
GCDL, GSML: 1 STRK 
GSAM: 1 TLAM + 1 SOF 
GSA3:2STRK(1 F18S) 

GSA6: 2 TLAM (from 2 different platforms) 
GRGF: 2 STRK 

AAC, APH, ACDM, AXOC: 1 AAW 
ACAP: 2 AAW 
AMIS: 1 ABM 

- other/unanticipated tasks via HELP 


1SOF+2STRK +1FAB 


* indicates that these must be distinguished from neutral (or decoy) counterparts 
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Both the organizational structures, functional (F) and divisional (D), consists of a 
six-node matrix describing six specialized missions (strike or surface warfare) and six 
multiple platforms (ships). As shown in Figure 2.6, the functional structure (F) is 
organized such that each player (DM) specialized in a single aspect of the mission over 
the entire battle space, controlling relevant assets that were distributed across multiple 
platforms (ships). This is reflected by the column s in Figure 2.6. The D organization is 
represented by the rows in Figure 2.6 and shows that each of the six players owns one of 
the major platforms with multifunctional capabilities. 


Functional 


DM 


1 

2 

3 

4 

5 

6 


Platform 

STRIKE 

BMD 

ISR 

AWC 

SuWC/MINES 

SOF/SAR 

1 

CVN 

2F18S 

XXX 

1UAV 

2F18A, E2C 

1FAB, 1MH53 

1HH60 

2 

DDGA 

8TLAM 

3ABM,4nOM 

1UAV 

6SM2 

1FAB, 2HARP 

1HH60,1SOF 

3 

DDGB 

8TLAM 

3ABM,4nOM 

1UAV 

6SM2 

1FAB, 2HARP 

1HH60,1SOF 

4 

CG 

8TLAM 

3ABM 

1UAV 

6SM2 

1FAB,2HARP,1MH53 

1HH60 

5 

FFG* 

2F18S 

XXX 

1UAV 

2F18A,E2C,4SM2 

1FAB,2HARP,1MH53 

1HH60 

6 

DDGC 

8TLAM 

3ABM,4nOM 

1UAV 

6SM2 

1FAB, 2HARP 

1HH60,1SOF 


* FFGs fixed wing aircraft are located on an isiand Air Operation Facility (AOF) 
SOFs are pre-inserted and located on a Forward Operating Base (FOB) 


AAW = anti-air warfare 
Mines = mine-clearing 
operations 

ASuW = anti-surface 
warfare 

BMD = ballistic missile 
defense 

Strike = strike warfare 
SAR = search and 
rescue 

SOF = special/ground 

operations 

ISR = 

intel/survellance/recon 


Figure 2.6 - Divisional (D) and Functional (F) Organizational Structure. The (D) 
organizational nodes are depicted horizontally and the (F) nodes vertically. 


In the D organization each player is a “platform commander” while in the F 
organization he/she is a “warfare area commander”. 


As has been noted, the distinction between the two scenarios (f) and (d) is based 
upon the resources requirements for the tasks. Therefore, by adjusting the resource 
requirements of selected task classes, it becomes possible to manipulate what the 
congruence model postulates, that inter-DM coordination is a major contributor to 
workload and a detriment to efficiency. Thus, the degree of predicted (structural) 
congruence is inversely related to the amount of inter-DM (inter-nodal) coordination 
needed to accomplish the mission. The design of the task classes for both scenarios, as 
shown in Figure 2.7, made it possible to manipulate the inter-DM coordination needed to 
successfully accomplish these tasks for the organization-scenario pairing. For example. 
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the resource requirements for the major mission tasks in (f) were adjusted to require 
coordination among two or more DMs in D but not in F. 
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scenario (f) scenario (d) 

Figure 2.7 - Task resource requirements 


The results obtained from E8 demonstrated that performance in the congruent 
cases significantly exceeded that in the non-congruent cases. Based on the comparison of 
the matched cases (D-d and F-f) with the mismatched conditions (D-f and F-d) the results 
show that communications and workload were increased in the mismatched conditions. 
Finally, participants in both organizations processed fewer tasks in the incongruent cases. 
Experiment 8 demonstrated the power of model-based organizational design for 
optimization of mission effectiveness. 
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III. VIRTUAL DESIGN TEAM (VDT) 


The VDT (Jin and Levitt, 1996; Kunz et al, 1998; Levitt et al, 1994) researeh was 
initiated at Stanford University in the late 1980s. The long term goal of the researeh is to 
develop eomputational tools to analyze decision making and communication behavior 
within organizations. 

A, INTRODUCTION 

The basic premise of VDT is based on information processing view of 
organizations (Galbraith, 1977). According to Galbraith (1977:3), organizations are 
'^composed of people and groups of people in order to achieve some shared purpose 
through a division of labor integrated by information-based decision processes 
continuously through time." Organization design involves bringing these factors together 
with the choice of strategy, that is, searching for a ‘fit’ between strategy, method of 
organization and integration of individuals (Galbraith, 1977:5). Galbraith put forward 
arguments to the effect that "dhe greater the task uncertainty, the greater the amount of 
information that must be processed among decision makers during task execution in 
order to achieve a given level of performance" (Galbraith, 1977: 36). 

VDT operationalizes and extends Galbraith’s framework to generate specific 
predictions about information processing capacity versus load at the level of individual 
actors or subunits. Actors send and receive messages to and from other actors along pre 
defined channels of communication, which in turn are dependent upon the exceptions 
generated during processing of tasks. Each actor has a queue of information tasks to be 
performed (e.g., work activities, attending meetings) and a queue of information outputs 
(e.g., completed work, request for assistance) (Nissen, 2003). Actors may be constrained 
by a number of factors like number of individuals in that position, work volume, and 
downtime. Performance is directly affected by factors such as how well the skill set of the 
actor matches those required for the task, his/her backlog and the relative priority of the 
task. 
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VDT also quantifies the effeet of a variety of organizational deeision-making 
polieies (e.g., the level of centralization of decision-making) on the handling of 
exceptions and the likelihood that they will be responded to. VDT thus generates specific 
predictions about activity and project schedule, cost and work process quality for a given 
organization assigned to specific project tasks. Relatively simple, high-level VDT models 
may contain five to ten business milestones, each enabled by a few tasks, assigned to 
fewer than twenty organizational actors. These relatively sparse models describe complex 
projects in sufficient detail to make extremely accurate predictions about schedule, cost 
and quality performance. Figure 3.1 shows the inputs and outputs of a VDT model. 


Controls 

Organization (Structure) 
Process Description (Activities) 
Actors (Skill levels) 
Communication Tools 


Inputs (variables) 

Organization (Structure) 
Process Description (Activities) 
Actors (Skill levels) 
Communication Tools 




>> 


VDT 

Simulation 

Model 

~r~ 


Outputs (“Measures of 
Progress”) 

^ Process Quality 
Total Cost 
Time 

Various Risk measures 


Mechanisms 

Actor, Activity, p-behaviors 


Figure 3.1 - VDT Model Architecture. Given values for independent input 
variables that describe a project and a set of fixed assumptions, the VDT model 
simulates each activity being performed by responsible actors and computes 
overall project duration, cost and coordination quality. The micro behaviors 
consider both planned direct work and inferred requirement for coordination and 
rework. 


For a particular analysis, a set of organizational attributes are held fixed as control 
variables and a small set of variables are changed as independent variables in the 
simulation. The fixed attributes are defined in behavior matrices that have been 
developed based on real world organizational behavior. For example, with low 
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centralization, the decision about whether to perform rework when an error is detected is 
made by the actors themselves while in the ease of higher eentralization the deeision 
would be referred to project manager. VDT also allows users some eontrol over these 
variables. Variables like skill level and degree of centralization ean be set by the user. 
Organization (Strueture), Proeess Description (Activities), Actors (Skill levels), and 
Communieation Tools depend upon fixed as well as user defined attributes. Henee they 
are listed under Controls as well as Inputs in Figure 3.1. The fixed aspeets are represented 
as Control and the variable aspeets are represented as Inputs. 

The VDT system is an object oriented, discrete event simulation tool. The model 
uses inheritance and behavior methods using symbolic pattern matehing. The VDT 
discrete event simulation of stoehastic behaviors uses Monte Carlo simulation. It uses 
editable decision tables (behavior matriees) to transform qualitative attribute values to 
quantitative values that are used in discrete simulation. The degree of centralization of 
deeision making responsibility affeets the outcome of the simulation. It is used to 
determine who will take deeisions about whether to perform rework when an error is 
generated. The deeision table also determines the probabilities that managers at each 
level deeide to rework, eorrect or ignore the error. The interplay between symbolie 
inference and numerieal Monte Carlo simulation enables VDT to replicate Galbraith’s 
predieted behaviors for an organization (Levitt et ah, 1996). 

B, OVERVIEW OF MODEL BUILDING 

SimVision™ is a commereial implementation of the VDT model by Vite 
Corporation that is licensed by ePM, Inc. This project uses SimVision™ (henceforth 
referred to as VDT) to emulate organizational behaviors from DDD Experiment 8. 

VDT is a complex modeling environment and it is the aim of this ehapter to 
introduee basie eoncepts to the reader. To know about VDT in detail the reader is urged 
to refer the SimVision™ user’s guide (Revision 7: January 15, 2003). 


21 



VDT models consist of two major components: task structure and organization 
structure. Task structure defines the work to be done and how individual tasks are related 
to each other while organization structure defines the shape of the organization (e.g., 
degree of centralization, teams, and sub teams). VDT provides great flexibility to change 
various parameters for both these structures in order to customize the model to suit user 
requirements. The simulated outcome depends on how well the complexities of the tasks 
are matched to the capabilities of the responsible positions. 

VDT employs graphical components (e.g.. Positions (human shapes). Meetings 
(parallelogram). Tasks (rectangles). Milestones and links) to build models (Figure 3.2). 
Objects used to represent work, events, and personnel in the model — such as projects, 
tasks, milestones, meetings, organizations, and positions — are referred to as shapes. The 
various means used to connect shapes to one another in order to express their 
relationships are called links. Users can define properties for each of these shapes and 
links. 



Figure 3.2 - Basic building blocks of a project 

A model consists of the model or program page. A program is a set of related 
projects that together produce the product or products. It also includes the associated 
responsible organizations, milestones, and relationships between projects. For example. 
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consider development of an IT product that requires a software and a hardware 
component. Both these eomponents may be represented by separate projects within the 
same program. Similarly, there can be two organizations representing software and 
hardware developers separately. Organizations may be linked to specific projects or left 
independent. If left independent, the persons within organization are available for all the 
projects within the program whereas if assigned to a project, they are available for work 
only for that project. Each project and organization has its own window. Milestones are 
used to define waypoints in the program and can be used to group a set of tasks (Figure 
3.3). Two milestones. Start and Finish, are defined by default in each program and project 
window. 

A project is a set of related produet development tasks ineluding positions (groups 
of one or more individuals) that perform tasks and the dependencies between tasks and 
positions. Each project is represented in its own window (Figure 3.2). Tasks are linked 
together for either sequential or parallel exeeution depending upon the objective. They 
are specified by the volume of work required (defined in man hours, days or weeks) and 
the skill required for completion of the task. Positions are represented in the projects 
using graphical human shapes. Eaeh position represents a group of people who may be 
defined by either the number of FTE’s (Full Time Equivalent people) or by staffing 
individuals from departments. The positions in an organization are linked together in 
desired hierarchy using Supervision links. Each task is assigned to one or more positions 
with one of them assuming primary responsibility for the task. Eaeh position, in turn, 
could be assigned to one or more tasks that are executed depending on the task sequence 
and priority (Figure 3.3). 

Organizations, like projects, are represented within their own window. Eaeh 
organization ean have one or more departments that can be staffed with people. Persons 
within departments are assoeiated with properties such as name, number of FTE’s and 
one or more skills. They are used to staff positions in the projeet window. 
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Positions or persons can be assigned to meet using the Meeting object. Meetings 
are gatherings of actors to communicate about the project and project tasks. One or more 
actors can be assigned to meet at predefined times and intervals (Figure 3.2). These 
meetings depend upon and affect the amount of coordination required. However, they 
also increase work backlog. 

A link shows a relationship between two objects and any dependencies one object 
has on the other. The various links available include task links, rework links, 
communication links, supervision links, assignment links and meeting links. Some of the 
major links are shown in Figure 3.2.They are used to link tasks to tasks, positions to 
tasks, or positions to meetings. They enable us to create sequential, pooled or reciprocal 
dependency among tasks. 

Models can be simulated once they have been constructed (Figures 3.3 and 3.4). 
The simulator results include the following information: 

• The predicted time to complete a project. 

• The total effort required to complete the project. 

• Several measures of process quality. 

VDT offers extensive text and graphical analysis of the model. Using charts and 
data that result from simulation, one can identify risks in the project, organization, and 
performance. Some of the graphical representations include Program and Project Gantt 
charts. Summary statistics. Schedule growth chart. Breakdown chart. Coordination chart 
and Quality risk chart. Planned and simulated project progress is presented using Gantt 
Charts (Figure 3.6). The user can also view position and person backlogs to identify 
overloaded positions or persons. Model analysis using VDT helps in pre project strategic 
planning, effective organization design and staffing, periodic program and project 
checkup and process refinement. 
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c. 


HOW TO BUILD AND ANALYZE MODELS 


Model building starts with creating a new program in VDT. The default program 
consists of a default project linked with Start and Finish milestones. The default project 
includes a default task, a default position, default milestones (Start and Finish), and a 
default meeting (Figure 3.2). The user can then add additional objects depending upon 
the requirement. 

Once the basic model has been constructed (called the baseline model where all 
error probabilities [see below] are set to zero), it is checked against predicted outcomes 
by simulating the model. If the simulated results match the predicted results the baseline 
model is assumed to be correct. Further enhancements to the baseline model can be done 
by adding communication and rework links and setting appropriate values for the error 
probabilities. These links make the model more representative of some real-world 
applications by introducing elements of communication, interdependency and 
coordination within the project. 

To quantify the distractions in a model such as the exchange of information, 
telephone calls, impromptu meetings, and rework caused by failed tasks, four different 
probabilities (Information Exchange Probability, Noise Probability, Functional Error 
Probability, and Project Error Probability) can be set in the program window. The 
information exchange probability measures the level of communication in the project 
between positions that are responsible for tasks linked by communications links. Noise is 
a way to measure the effect of interruptions in the ordinary working day that take time 
away from doing the project tasks. Eunctional error probability is the probability that a 
task will fail and require rework. Project error probability is the probability that a task 
will fail and generate rework for all dependent tasks connected to it by rework link s . 
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A sample model developed as part of this project is shown below. 



Figure 3.3 - A sample model 


The model in Figure 3.3 comprises four parallel (simultaneous) tasks. A position 
(Position 1) is responsible for executing these tasks. Each of these objects has various 
properties that can be set in the properties window. The variable properties for a task that 
can be set are seen in Figure 3.4. 



Figure 3.4 - Task Properties 
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The various properties assoeiated with tasks inelude name, deseription, priority, 
work type, and skill among others. Priority is the importanee of a task relative to others in 
the projeet, expressed as High, Medium, or Low. By setting a task’s priority, one ean 
influence how a position will treat it compared to other tasks occurring in parallel (i.e., 
simultaneously). Positions tend to attend to tasks in order of priority. Tasks with highest 
priority tend to receive attention before lower priority tasks. Thus, highest-priority tasks 
tend to finish before lower-priority tasks. 

A task’s work volume determines how long it is expected to take. There are three 
types of work volume to set for a task: Work Volume, Work Duration, or Max Duration. 
Work volume is the amount of work that needs to be done to complete the task. If more 
FTE’s are assigned to the task then it will be completed in lesser time. Work duration is 
the amount of time the task takes. Work duration is used for tasks whose duration is 
determined by factors other than the number of FTEs assigned. Rework and coordination 
can cause the task to take longer than specified when specified in terms of work duration. 
Max duration is used for tasks whose duration is determined by factors other than the 
number of ETEs assigned. These tasks are not constrained by their work volume but by 
time, and where coordination and rework do not affect the task. 

Skill is the primary area of expertise needed to perform a task. The default skill is 
Generic, indicating that the task requires only those abilities possessed by the average 
worker. Other skills can be added to the project, thus enabling selection of a skill more 
appropriate to the task’s requirements. In the above project all the tasks have a differing 
priorities, generic skills and work type property is set to max duration. 

Various properties associated with positions can be seen in Figure 3.5. They 
include, among others, name, description, role, application experience, FTE, skill set and 
staffing. The role describes the position’s organizational function on the project team. It 
also affects the types of decisions that are made by that position. There are three types of 
position roles: Project Manager (PM), Subteam (ST) and Subteam Eeader (SE). Usually 
only one person is appointed PM in a project. The Subteams actually do most of the 


27 



work. This is the default role. The ST passes some exeeptions to the Sub team Leader 
(SL), whieh in turn passes some exceptions to the PM. All positions between ST and PM 
are designated as SL. The PM normally generates more rework than the SL, which in turn 
generates more rework than the ST. Application Experience describes how experienced 
the position is with this type of project. There are three values for application experience; 
high, medium and low. Because of its effect on position work processing speed, 
application experience has a dramatic effect on project duration, internal and external 
exceptions. The position FTE value shows the number of full-time equivalent (ETE) 
people that an unstaffed position represents. A position can represent multiple full-time 
people, part-time people, or a combination of both. The Skill Set displays the skills that a 
position has available and the position’s skill level (high, medium or low) in each of these 
skills. Staffing represents the person or persons assigned to the position. These persons 
usually belong to departments that are defined in the Organization window. In the above 
project (Figure 3.3), Position 1 is an unstaffed ST, has medium application experience, 
generic skill, and a FTE of one. 



Figure 3.5 - Position properties 


Simulated result for the above model is as shown below. 
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Figure 3.6 - Simulated results for the sample model 


The simulation provides eomparison between the planned dates, simulated dates 
(not in figure) and the eritical path (CPM) dates. Planned dates are the dates assigned by 
the user and are run through the simulator only to allow for eomparison against the 
simulated and CPM dates. The principal difference between simulated and CPM results is 
that simulated results take into account all the real-world factors that have been modeled, 
whereas CPM results reflect an optimistic scenario where all positions are fully available 
to work all the time on all their tasks unless the tasks overlap. For example, simulated 
results factor in time for communications between positions about tasks, exceptions in 
tasks, and the resulting rework and possible backlog for the responsible positions. CPM 
results ignore all these factors. VDT also provides various other charts and data to 
interpret the simulation results. In addition to Gantt charts, the user can check Project 
summary. Person and Position backlogs. Project breakdown. Project schedule growth and 
various risks associated with the project. 


VDT offers numerous features to model and control various aspects of a project 
or a program. In our project however, we will restrict ourselves to using some of the basic 
features and allow the software to keep default values for all others. 
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D, CONCLUSION 


The VDT framework is ideal for this projeet beeause it distinguishes individuals 
and their roles, represents dynamie changes in the organizational work environment, and 
provides detailed traces of participants executing work process and communication tasks. 
The primary challenge of this project is to take the VDT out of its commercial use and 
explore its potential for modeling organizational parameters in a military context. 
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IV. SIMILARITIES AND DIFFERENCES 
BETWEEN DDD AND VDT 

The previous two ehapters have described the main simulation tools that are 
central to our project: the Distributed Dynamic Decision-making (DDD) simulation 
system - a real-time, team-in-the-loop war-gamming environment, and SimVision™ - a 
commercial implementation of the VDT (Virtual Design Team) simulation model, used 
for projects management. 

We considered VDT well-suited to study the effects of context on organizational 
performance as it includes basic elements that represent individual actors, their decision¬ 
making preferences, the organizational structure, decision-making policies and 
performance metrics. In addition, both DDD and VDT are relatively mature products 
that have demonstrated excellent utility in past applications. Both products appeared to 
exhibit many synergisms that offered possibilities for exploitation in our research. 
However, there were also several differences that, if not resolved, could adversely affect 
our objective of applying VDT to the DDD environment. 

During our participation in DDD Experiment 8, we observed six decision makers 
(DM’s) playing a war-gaming scenario in which the DM’s communicated over a voice 
network in order to coordinate team activities. Supposedly VDT could be used to model 
this scenario, and the team coordination processes, within a hypothetical model. 

VDT was designed to simulate alternative options (by planning, running the 
simulation, acknowledging how feasible the plan was, having the opportunity to go back 
and refine it, etc.). In contrast, in DDD, instead of simulating multiple alternatives, the 
alternatives are in the minds of the players and only a single alternative can be played in 
any real-time run. Thus, the A2C2 research team saw potential value in being able to 
model alternative architectures using VDT in order to complement A2C2 research 
wherein military officers play alternative architectures in a DDD simulation. 
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A. 


LEARNING THE FUNDAMENTALS: MODELING BASIC TASKS 


In an attempt to understand the DDD/VDT differenees, we started by eomparing 
the two tools with the aim of finding the appropriate mateh between their relevant 
operating parameters. Running SimVision tutorials, we learned that some VDT features 
exhibited a very straightforward eorrespondence with DDD. Both DDD and VDT had 
“Start” and “Finish” points, “Tasks” and “Milestones” in a sequenee dictated by the 
planned/modeled scenarios. This similarity is illustrated in Figure 4.1 where we compare 
a simplified task graph (abstracted from the scenario used in A2C2 Experiment 8) with a 
default project sequence, as it appears in the VDT model pane. 


Excerpt from Eundamental task Graph A2C2 Experiment 8 



Excerpt from Model Pane - SimVision™ 


Start 



Projecti 




Rnish 


Figure 4.1 - Simple correspondence between a task graph scenario used in A2C2 
Experiment 8 and a default project sequence - VDT. 

The primary mission tasks in Experiment 8 are shown on the task graph as circles 
linked with “finish-start” arrows in a planned sequence, having an initial “START” point, 
and a final objective - “PORT”. In VDT, we also have “Start” and “Einish” points. 
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interconnected with “Project 1” box using “finish-start” arrows. The “Project 1” box can 
be “decomposed” further to model the same sequence of tasks illustrated in the task graph 
of Figure 4.1. The primary tasks shown in Figure 4.2 by rectangles are interlinked with 
milestones, using the same “finish-start” arrows. 

Similarly, a number of different kinds of tasks in the Fundamental Task Graph of 
Experiment 8, such as: primary tasks (the enemy command center - CMD CTR, the 
enemy air bases - ABE/ABW, the enemy naval bases - NBE/NBW, and the final 
objective-PORT), time-critical tasks (destroying SCEID launchers, search and rescues, 
etc.), offensive prerequisite (e.g., mine clearing), or defensive tasks - could be easily 
replicated within VDT. 


Excerpt from Model Pane - SimVision™ 



Eigure 4.2 - Detailed VDT “Project 1” box, following the same sequence as in the 
simplified task graph - A2C2 Experiment 8, depicted in Eigure 4.1. 

As briefly described in the previous chapter, task precedence can be very simply 
modeled in VDT using successor li nk s: “finish-start” (the successor task starts when the 
predecessor task finishes, or also a specified time delay following finish), or “start-start” 
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links (the successor task starts at the same time as, or a specified time after the 
predecessor task starts). 

At this point, after envisioning success in modeling the mission tasks, we also 
thought that time-critical tasks could be placed in the sequence as planned in DDD, and 
that VDT should be able to handle the assets for these tasks. In general, for some of the 
VDT parameters we could see some fairly clear links to parameters in DDD, for others 
these links were less obvious. In some cases, however, the two differed more 
substantially. For Example, in DDD/Experiment 8 the decision makers were not 
hierarchically differentiated as they are assumed to be in VDT. Experiment 8 used a 
“flat” structure, not an organizational hierarchy. Eurthermore, the positions’ 
training/experience, which intuitively affects the results, is not included within the DDD 
model but is part of VDT. 

B, MODELING THE ASSIGNMENT OF ASSETS/RESOURCES TO TASKS 

Another representational issue was that DDD/Experiment 8 assigned assets to 
tasks rather than positions to tasks, as done in VDT. The basic elements of the VDT 
model include the decision makers/positions in an organization, and the tasks that 
comprise a work process. Each position has attributes such as skill set, level of 
experience, and organizational role. 

Our initial view was that we could define parameters in VDT such that positions 
would be characterized as assets/platforms (e.g.. Aircraft carriers - CVN; Aegis-capable 
destroyers - DDG), “staffed” with different sub platforms or weapons (standard surface- 
air missiles - SM2; anti-ballistic missiles - ABM), and having different “skills” (SM2 - 
“anti-air” skill etc.). Eurthermore we assumed that we could assign assets to primary and 
secondary tasks using the primary and secondary assignment links (as described in 
Chapter III). We also planned to use the VDT “ETE” feature (the number of full-time 
equivalent persons represented by the position) to establish the number of sub 
platforms/weapons under a certain asset/platform. 
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An additional concern was related to “task work volume”, which in VDT 
represents the amount of work one prediets the task will require. There are various ways 
to express this “work volume” - person hours, weeks, and months. However, this work 
volume represents only the direct work of the task; during VDT simulation, the task may 
require more time due to coordination tasks and rework. These comprise the 
information-proeessing requirements of the task. The elosest parameter to work volume 
in DDD is “workload demand”, used by the modelers to balanee asset management and 
effort among DM’s. Eaeh DM is prompted by the DDD simulator to provide an 
“estimate of the workload they experiencing” (Diedrich et ah, 2003) as a way of data 
gathering on workload assessment during scenario. Based on the modeling approach and 
the manipulations relative to the DDD congruent and incongruent cases, the overall level 
of perceived workload should be higher in mismatched cases. 

Another resource parameter that we attempt to find a DDD eorrespondence with 
is referred to in VDT as “skill”, that is the ability of a person to perform a speeific task. 

In DDD/Experiment 8, the six primary platforms did not have any native or organie 
eapabilities - all of their organic capabilities derive from their sub platforms and weapons 
systems. We eould model this in VDT, by assigning a “generic” (general) skill to the 
primary platform while assigning specific skills to the organic sub platforms and weapon 
systems. 

C. MODELING COORDINATION 

Another VDT feature that had no straightforward eorrespondenee to 
DDD/Experiment 8 was the option to set meetings among decision makers as a means to 
improve communication and reduce the rework. It seems that VDT measures the quality 
of eommunieation among DM’s by tracing the fraetion of communications responded to 
and meetings attended. Bottom-line; the more meetings (coordination) attended, the 
better the performance. However, we found this feature apparently without direet 
correlation with DDD/Experiment 8, as there were no scheduled meetings but rather open 
communication links established among the decision makers. Moreover, in DDD 
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extensive (real-time) eoordination is a detractor to performanee, in terms of additional 
workload and eonsequent time delays. 


D, USING VDT PROBABILITIES TO MODEL THE LEVEL OF 

COMMUNICATION/COORDINATION, WORK DELAYS, AND 

REWORK 

The behavior of the VDT model is determined probabilistieally, and simulated 
stoehastieally. As we have briefly deseribed in Chapter III, VDT, allows the user to set 
probabilities (information exehange, noise, funetional error and projeet error 
probabilities), thereby introdueing an element of error into the projeet that makes it eloser 
to reality. 

1. Modeling the Level of Communication 

VDT uses the information exehange probability to measure the level of 
eommunieation within the projeet between positions responsible for tasks linked by 
eommunieations links. In DDD/Experiment 8 eommunieation and eoordination are 
driven by varying degrees of task interdependenee. To model this using VDT, we 
planned to use the exehange probability rate by setting it to a higher value for 
ineongruent projeets and a lower value for eongruent ones. 

2. Modeling Work Delay and Rework 

The probability of noise used in VDT is “to aeeount for the effeet of interruptions 
in the ordinary working day that take time away from doing the projeet tasks” 
(SimVision™ Tutorial, 2003). This may find eorrespondenee in DDD/Experiment 8 with 
the leveEprobability of oeeurrenee of unpredieted tasks and defend tasks that eould divert 
the DM from performing an ongoing task, eausing delays or even rework. 
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Functional error probability - the probability that a task will fail and require 
rework, has no direet eorrespondenee in DDD/Experiment 8; it does not seem useful to 
ineorporate rework links between interdependent tasks as long as the mission goes ahead 
without rework, and the probability of a weapon failure onee launehed is elose to zero. 
However, there eould be many eritieal eases in whieh targets are not destroyed on the 
first try, additional sorties are flown, or additional elearing operations are eondueted. 
(The DDD allows for sueh “funetional error probability” although it was not utilized in 
Experiment 8.) Another faetor that is implemented and measured in DDD is the total 
number of wasted attaeks (NumWast) that oeeurs when a task is attaeked when the task’s 
prerequisites are not met. 

The addition of rework links may signifieantly eontribute to more realistie VDT 
simulation results. The same reasoning may apply in the more eomplex but not 
unrealistie instanee that implies the projeet error probability - “the probability that a task 
will fail and generate rework for itself and all failure-dependent tasks, whieh are tasks 
eonneeted to it by rework links” (SimVision™ Tutorial, 2003). 

E, COMPARING VDT AND DDD OUTPUT 

Repeated simulation of a VDT model yields a database of organizational behavior. 
The database eontains expeeted outeomes related to the sehedule, eost, and quality of 
eaeh simulation experiment. VDT traeks the final sehedule duration of the entire work 
proeess, as eompared with the projeeted duration based on Critieal Path Method (CPM) 
analysis (whieh assumes no errors, and no explieit eommunieation or rework). VDT 
traeks the projeet eost based on the salaries of the employees, but does not inelude task- 
related eosts. Also, VDT eomputes the pereent of a task's work volume that is direet 
work, versus the pereent spent in eoordination and rework. 

Using the DDD Post Proeessor V2.1 (a database applieation designed to analyze 
experimental data after eaeh DDD experiment) a vast amount of DDD output data ean be 
transformed into useful information that ean be exported to other statistieal paekages for 
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further analyses (Wong, Kleinman, 2002). The DDD results ean be plotted, filtered or 
drilled-down and eompared by dependent variables, seenarios, teams, or decision-makers. 
The summary data contain a large set of observed dependent variables (DV) including the 
average response time (time of request - time of report), the average latency (time 
between task arrival and attack), the total gains/losses based on scoring method, the total 
number of wasted attacks (i.e., prerequisites not met) etc. 

F. MODELING DESIGN TRADE-OFFS 

A key research question is whether the behaviors replicated by VDT can apply in 
the DDD/Experiment 8 environment. A primary tension in any modeling effort lies in 
how much of the observed world one includes or excludes. Through modeling a complex 
system is simplified and abstracted to its most relevant essentials, while still making 
useful predictions. The choices a model-builder makes ultimately determine the 
questions the model can answer. And one very important choice is the level of detail, or 
granularity, at which the organization and its work is represented (Fridsma, 2003). 

In our research we were aware that the goal was not to have VDT models resemble DDD 
models. Rather the goal was to develop VDT models that could reflect key behaviors of 
military forces in combat. Furthermore, in terms of validating our VDT models, such 
validation was not supposed to be against DDD models, but rather against the results of 
Experiment 8, which included human decision makers playing the DDD scenarios. 
Therefore, we were not concerned if our VDT models did not structurally match DDD 
models, as long as the replicated VDT behaviors could reflect qualitatively those 
exhibited during Experiment 8. 

However our efforts to find as many relevant correspondences as possible, and to 
ameliorate the differences between VDT and DDD/Experiment 8, were critical for 
assuring that the modeling process would exclude all irrelevant elements and also for 
gaining confidence in our predictions. Hence, the results of these comparisons were 
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subsequently exploited in our attempt to build simple independent VDT models to 
eapture the relevant DDD/Experiment 8 behaviors. 


G. IDENTIFYING DDD KEY BEHAVIORS 

The ultimate step here was to identify the DDD key behaviors and assess the way we 
eould possibly replieate them in VDT. The seleeted DDD key behaviors are briefly 
deseribed below: 

• Expendable assets - eoneerns the eharaeteristie of some DDD assets (e.g., 
missiles, fighter sorties) to get eonsumed after use. 

• Resource Scarcity - There are more task requirements than there are resourees 
available. If DM’s use more assets on a task than required, they are not available 
for use elsewhere. 

• Task precedence/prerequisite - This relates to the sequenee that should be 
followed when aehieving speeifie tasks (e.g., elearing a minefleld before landing 
on a beaeh), whieh require prerequisite (or eorequisite) aetions (Kleinman et ah, 
2003). 

• Tasks Prioritization - A DDD feature is the presenee of eonflieting task 
requirements that requires prioritization (e.g., shifting to a defensive task while an 
offensive is underway). 

• Time criticality of tasks - There are time eonstraints in the performanee of eertain 
tasks. If that is time eritieal tasks are not aehieved there are eonsequent easualties 
or assets lost (e.g. SAR tasks, destroying enemy’ SCUD launehers). 
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• Multiple skill requirement tasks - Some DDD tasks require multiple skills to be 
eompleted (e.g., destruetion of Command Center requires two units of Strike and 
one unit of SOF). 

• Coordination requirements - There are DDD parallel proeessing tasks, where 
assets owned by different DM’s are to be eoordinated in time and spaee (e.g., a 
eomplex task that may require an air, naval and ground attaek). 

• Geography - This is an important and eomplex DDD feature implying 
eoordinated aetions of DM’s using different assets from different locations. 

At this stage, we were not entirely aware of what we could or could not replicate in 
VDT. However, as part of the modeling design process we planned to follow an iterative 
course of action allowing us to go back, reassess and refine the models to try to capture 
these behaviors using VDT. This process of replicating the selected behaviors building 
and refining the models is described in more detail in Chapter V. 
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V. MODELING WITH VDT 


The aim of VDT research is to develop computational tools to analyze decision 
making and communication behavior within organizations as discussed in Chapter III. It 
is an excellent tool to model projects in the corporate world. The aim of this project is to 
explore its potential for modeling organizational behaviors in a military context as 
represented by DDD Experiment 8 (herein referred to as DDD), discussed in Chapter II. 

In this chapter we narrate the steps taken towards fulfillment of our objective. The 
aim is to develop a VDT model that replicates the key behaviors identified in DDD 
experiments. The sections below summarize steps undertaken toward this end. 

A. LEARNING VDT AND DDD 

The first step in this project involved getting familiar with VDT. Towards this 
end, licensed copies of VDT were purchased and all the project members familiarized 
themselves with the software by reading the User Manual (SimVision^'^ User Guide) and 
working the tutorials supplied with the software. Also, to understand the theory behind 
VDT, the project members referred to various papers and articles published on the subject 
(Jin and Levitt, 1996; Kunz et al, 1998; Levitt, R, 1996, Nissen et al, 2003). 

In parallel, team members familiarized themselves with the workings of DDD, in 
particular with A2C2 Experiment 8. Towards this end team members referred to 
published material (Diedrich et al, 2002, Kleinman et al, 2003, Diedrich et al, 2003, 
Kleinman D, 2001) and also obtained first hand knowledge by observing a demonstration 
of Experiment 8 in progress. Team members also attended a players briefing for 
Experiment 9 to develop an appreciation for the nature of complexities involved. 
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B, IDENTIFYING KEY MODEL BEHAVIORS 

Our primary objective was to build a representative model in VDT that replicates 
the performance and behaviors in DDD. The DDD task and organization structures 
consist of many complex scenarios. The team decided that in order to build a complete 
model we need to identify and model simple but key behaviors in DDD that will provide 
the building blocks for the final model. These behaviors have been discussed earlier in 
Chapter IV Section IV.G. Summary descriptions of these behaviors are presented below. 

1, Expendable Assets 

In DDD, each weapon asset (e.g., missiles, TLAM’s, and ABMs) gets consumed 
after use. On the contrary, in VDT, actors do not get “consumed”. After they are finished 
with a task they move on to the next one. The critical question here was how to build a 
model where an actor is used only once. 

2, Resource Scarcity 

In DDD, each target has specific resource requirement and if players use more 
than the required assets (e.g., firing two missiles when one is required) against a target 
these assets are unavailable for use elsewhere. VDT, by design, does not limit use of 
actors. If a position has more than required actors then all of them will be used and the 
task will be completed in a shorter period of time. The critical question here was how to 
restrict the use of resources by actors such that a resource scarcity can be created. 

3, Task Prcccdence/Prercquisitc 

In DDD, certain tasks were sequential wherein prerequisite tasks had to be 
completed before undertaking primary ones (e.g., destruction of Bridge prior to 
destroying NBW). The critical question here was how to structure the programs, projects 
and organizations such that the task structure replicates the DDD task graph. This could 
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however be done easily in VDT by placing individual tasks in parallel/sequential with 
respect to other tasks. 

4, Task Prioritization 

DDD was setup in such a manner that there were conflicting task requirements 
and the players had to prioritize them (e.g., shifting to a higher priority defensive task 
while an offensive is underway). The critical question here was how to assign varying 
priorities to tasks such that the order of execution is correctly determined by VDT. 

5, Time Criticality of Tasks 

In DDD, there were certain time dependent critical tasks that had to be assigned 
higher priority in order to successfully complete the mission (e.g., defensive tasks). If a 
player did not defend then he would lose some assets. Moreover, to the player, these tasks 
appeared randomly. The critical question here was how to model such tasks within the 
overall task structure given the difficulty of modeling random tasks within VDT. 

6, Multiple Skill Requirement Tasks 

Some tasks within DDD, especially the ones in the divisional scenario required 
multiple skills to be completed (e.g., destruction of Command Center requires two units 
of Strike and one unit of SOF). This cannot be readily modeled in VDT since each task 
can have only one skill requirement. The critical question here was how to simplify the 
complex tasks by breaking them down into simple tasks. 

7, Coordination Requirements 

DDD required its players to coordinate before undertaking a task (e.g., tasks such 
as Command Center requiring multiple assets in the divisional task scenario therefore 
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required eoordination by several players). The eritieal question here was how to enforee 
eoordination among aetors in VDT. 

8, Geography 

Geography is an important eonsideration in DDD. There may be more than one 
player available with required assets for a task but if the target is outside one’s weapon 
range, he/she eould not undertake it. Moreover, attaeks from different plaees required 
different time units to eomplete the task (e.g., missiles fired from two different loeations 
would not reaeh the target simultaneously). The eritieal question here was how to ereate a 
seenario that takes into aeeount the geographieal aspeet of DDD simulation within VDT 
models. 


9. Departments and Staffing 

Departments and staffing eome into play when differentiating between funetional 
and divisional organizations. The eritieal question here was how to ereate departments 
and staff people sueh that the resulting organization replieated the funetional and 
divisional organizations in DDD. 

C. MODELING INDIVIDUAL BEHAVIORS 

Based on the knowledge gained from working the VDT tutorials, the team set 
about building simple independent models to replieate eaeh of these behaviors mentioned 
above. These key behaviors were short listed based upon our understanding of the DDD 
seenarios and upon diseussions between projeet members and our advisors. Sueeessful 
replieation of these behaviors was vital before we eould attempt to build the final model 
sinee all of these behaviors would need to be ineluded in it. These behaviors play a key 
role in determining the outeome in VDT experiments and henee were essential to our 
projeet. The models developed as part of this exereise are ineluded as an eleetronie 
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attachment to this report and the related file names have been indieated against each of 
the behaviors discussed below. 

1, Expendable Assets (Expendable,vpm) 

The team decided that the best way to model this behavior is to incorporate long 
meetings in the model in such a way as to commence the meeting after completion of a 
task and assign the related positions to the meeting. The meeting duration is set longer 
than the projeet duration to tie up that position until the completion of the project. The 
proposed model is a very low level model, in that eaeh asset/weapon (e.g., missiles) is 
represented by a position. The model and its simulated result are shown below: 



The model eonsists of three sequential tasks (Task 1, 2 and 3) and three positions 
(Position 1, 2 and 3). Figure 5.2 shows the task details. Each task is assigned to all three 
positions, however, only one position is assigned primary responsibility for eaeh task 
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(solid links) so that any position can undertake the task provided it is available. Two 
meetings (Meetings 1 and 2 related to Milestones 1 and 2 respeetively) have been plaeed 
such that Position 1 is assigned to attend Meeting 1 and Position 2 is assigned to attend 
Meeting 2 (Figure 5.3). The aim was to make Position 1 unavailable after Taskl is 
completed. Similarly Position 2 would also be made unavailable after Task 2 is 
completed and only Position 3 would be available to execute Task 3. Although this could 
have been simply done by linking only one position to a task, it would fail to meet the 
requirement specified in Section V.C.3 that assumes positions with multiple task 
requirements. 











□ Task Name 

Description! | Work Type 

Work Value 

Units 

Skills 

Requirement Complexi^ 

Solution Complexity 

Jncertainty 

Fixed Cost 

1 

Taskl 

Medium IMax Duration 

16 

Days 

Generic 

Medium 

Medium 

Medium 

0 

2 

Task2 

Medium iMax Duration 

20 

Days 

Generic 

Medium 

Medium 

Medium 

0 
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Tasks 

Medium IMax Duration 

22 

Days 

Generic 

Medium 

Medium 

Medium 

0 











_ 
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ReiAiorkA C 


Figure 5.2 - Task Deseription 


Table View 


S Meeting 

Name 

Description 

Priority 

Duration 

Units 

Repeating 

Meet Every 

Units 

Start Time 

First Meeting 

Rel/Abs 

Start Lag 

Units 

Schedule till 

1 

Meetingl 

IMedium 

200 

Days 

No 

1 

Weeks 

08:00 AM 

Miiestonel 

Relative 

0 

Days 

Till End 

2 

Meeting2 

iMedium 

200 

Days 

No 

1 

Weeks 

08:00 AM 

Miiestone2 

Relative 

0 

Days 

Till End 



<1 1 4 


14141 ►INI\Task A Milestone A Posion AMeetiop A Ghost Task A Ghost Milestone A Connector A Successor A Piimaty Assianmerls A Sec. Assianment A Supervisor A Rework A Communicafo 



Figure 5.3 - Meeting Details 


The simulated result for the above ease is shown in Figure 5.4 below; 


46 































































Milestone Nome 

Sim. Date 

Planned Date 

CPM Date 

Compaie Date 

Criticality 

2004 


Task Name 

Duration (days) 

Start 

Finish 

Float 

Criticality 


Meetirx! Name 

Duration 

Start Date 

Meeting Risk 

Interval 

# Meetings 

Feb |Mar |Apr |May|Jun 


Stall 

0220 04 

0220 04 



1 

♦ 

□ 

Expendable Sequence 

80,0 

02/20/04 

05/10/04 

05/10/04 

1 


■ 

Start 

0220 04 

0220 04 



1 

♦ 


Meetinql 

200,00 dai/s 

03/15/04 

0,28 

1.00 weeks 

1 



MeetinQ2 

200,00 days 

04/12/04 

0,28 

1.00 weeks 

1 



Taski 

24,0 

02/20/04 

03/15/04 

03/15/04 

1 


L 

Milestonel 

03 1504 [022004 



1 

♦ ♦ 


Task2 

28,0 

03/15/04 

04/12/04 

04/12/04 

1 



Milestone2 

04 12 04 

02 20 04 



1 

♦ 

■ 

Tasks 

28,0 

04/12/04 

05/10/04 

05/10/04 

1 


r 

Finish 

05 1004 

02 20 04 



1 

♦ 

k 

Finish 

05 1004 

0220 04 



1 

♦ 

|Piogitini Gdiitt: Piogidin 



Figure 5.4 - Simulated results (Gantt ehart) 


The Gantt ehart above shows the duration, start and end times for various objects 
in the model. Tasks are represented by red rectangles, meetings are represented by blue 
rectangles and milestones are represented by rhombus. The Gantt chart above shows the 
effect of the meetings in the project. Position 1 is involved with Meeting 1 upon the 
completion of Task 1 and is not available for Tasks 2 and 3. Similarly Position 2 gets 
involved with Meeting 2 after completion of Task 2 and is not available for Task 3. This 
behavior can be further seen from the position backlog chart shown below. 



The Position Backlog chart shows predicted overload of positions over time. The 
overload is expressed as a graph in terms of days for each of the positions in the project 


47 





















































































































model with backlog measured along y-axis and days along x-axis. The above chart 
clearly represents the cycle of events taking place within the project. Position 1 attends 
Meeting 1 after completion of Task 1 and his work backlog increases close to 170 days at 
approximately 03/11/04 on the timeline and remains same thereafter. Similar is the case 
with Position 2 that attends Meeting 2 after completion of Task 2 that indicates a high 
work backlog beginning approximately 04/08/04. This indicates that positions 1 and 2 
remain busy with meetings after completion of tasks 1 and 2 and are unavailable for 
further work until the end of project. 

The above model could successfully replicate the behavior in DDD where assets 
such as missiles get consumed after use. However, this scenario was modeled at a very 
low organizational level with each position representing just one asset. A similar attempt 
at a higher organizational level involving departments and staffing is presented in Section 
V.3.8. 


2, Task Precedence/Prerequisite 

Task precedence can be easily modeled in VDT using sequential tasks. No 
separate model was built for this behavior. However, as can be seen from Figures 5.1 and 
5.4, Task 2 commences only after completion of Taskl, and Task 3 commences only 
after completion of Task2. 

3, Task Prioritization (TaskPrioritization.vpm) 

This behavior is directly related to DDD, in that, players are given limited assets 
and are faced with multiple tasks that may occur simultaneously. Some of these tasks are 
high priority tasks such as defensive tasks while some are low/medium priority tasks such 
as destroying SAM sites. The players may have to switch between tasks during the DDD 
simulation. 


48 



The team felt that the best way to model this behavior is to assign overlapping 
tasks (by ineorporating varying delays for eaeh task) to a position with limited FTE’s and 
assign varying priorities to the tasks). Tasks are designed sueh that a high priority task 
eommenees while the low priority task is in progress. 

The model was designed with four parallel tasks (SAM, DEF, CMD and SAR) 
with varying priorities assigned to a position (Position 1) with an FTE of one. All the 
tasks and the position have generic skill property. Various delays are incorporated in the 
tasks such that task SAM has no delay, task DEF has a delay of six days, task CMD has a 
delay of 10 days and task SAR has a delay of 30 days. 


The model developed for this behavior is as shown in Figure 5.6, the various task 
properties are shown in Figure 5.7 and the various lags introduced before each task are 
shown in Figure 5.8. 



Figure 5.6 - Prioritization of tasks 
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Figure 5.7 - Task details (note the varying priorities) 



Figure 5.8 - Sueeessor details (Notiee the lags for the various tasks) 


Following Figure 5.8, it was designated that the task SAM starts almost 
immediately, followed by the task DBF after six days. Position 1 should ideally leave or 
halt the task SAM in order to focus on DBF, it being a higher priority task. Similarly, 
after ten days, once task CMD is available. Position 1 should ignore it since it is already 
engaged in a higher priority task, DBF. The simulated result for the model in Figure 5.6 is 
shown in Figure 5.9. 



Figure 5.9 - Simulated results (Gantt chart) 
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As can be observed from the above figure, the results do not match the 
assumptions made earlier. The Gantt ehart shows that Position 1 undertakes all the tasks 
concurrently and finishes them in exaetly the same order as specified in the model in 
Figure 5.6 (i.e., SAM - DBF - CMD - SAR). We can thus conclude that this model does 
not replicate the behavior of prioritizing and shifting task focus as required in DDD. 

4, Time Criticality of Tasks (TimeCriticalityofTasks.vpm) 

In DDD, eertain defensive tasks are time eritieal and have higher priority than 
others. The players are expected to halt other operations and take on these tasks at the 
earliest. VDT does not provide any faeility to speeify time dependeney for tasks (i.e., we 
cannot enforce VDT to eomplete a task within a speeifie time period). Tasks may only be 
placed in parallel or in sequence with other tasks and are then executed as per their 
respective position within the model. The attempted workaround for this problem was to 
introduce certain high priority tasks and make them prerequisite for the normal mission 
tasks. We then added delay for these high priority tasks such that they occur in the VDT 
model at the same time as they ‘appear’ in DDD. For example, if an enemy destroyer 
‘appears’ after 10 minutes of starting in DDD we ean delay the related task in VDT by 
the same faetor. A simple representation of the above is shown in Figure 5.10. 
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The above model eonsists of three sequential tasks with medium priority, generie 
skills and a work volume of 25 days. A fourth high priority task ‘Priority Task 1 ’ with 
generie skills and a work volume of 30 days is added. This task has been designed to start 
35 days after ‘Start’ and is prerequisite for executing Task 3. This can be seen equivalent 
to DDD where the player continues executing primary tasks and is faced with a defensive 
task after some point in time (35 days here). Simulated result of the above model is 
shown in Figure 5.11. 



Figure 5.11 - Gantt chart for Time Criticality of tasks 


The above result demonstrates the sequence of task execution. Normal Tasks 1, 2 
and 3 are executed in sequence while the Priority Task 1 commences after 35 days and is 
finished before undertaking Task 3. Position 1 has to divert resources from task 2 and 
hence Task 2 takes longer than Normal Tasks 1 and 3. 


5, Multiple Skill Requirement Tasks (Multiple Skill Requirement 
Tasks, vpm) 

Some tasks in DDD within the Divisional task scenario require multiple skills in 
order to be executed (e.g., destruction of the Command Center requires two units of 
Strike and one unit of SOF). Since VDT allows us to specify only one skill requirement 
for any task, the problem was to define a model that can successfully replicate the 
required behavior. 
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The project team decided that the best solution would be to break down multiple 
skill requirement tasks into simpler tasks, each requiring just one skill. These tasks are 
placed in parallel such that all have to be executed simultaneously. The added advantage 
of this solution is that communication links may be placed between these tasks and that is 
helpful in modeling the coordination required between responsible positions in order to 
execute these tasks. A model developed for the above construct is shown in Figure 5.12. 



Figure 5.12 - Model representing breakdown of complex tasks 

The above figure shows a representation of a single complex task that requires 
two skills, A and B, for successful execution. For example, the task set resembles the task 
CMD CTR in the DDD divisional task structure that requires two skills. Strike and SOF, 
to destroy it. The positions represent the players (say Strike and SOF commanders) such 
that each position is responsible for his/her part of the task set and need to coordinate 
with the other in order to execute the task successfully. Coordination is designated by the 
dotted line linking the two tasks. 
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Two skills have been established for the above model. While Skill A task and 
Skill A Position requires/have Skill A, Skill B task and Skill B position requires/have 
Skill B. The aim of this exereise was building a simple and intuitive model that would 
allow us to replieate multiple skill requirement tasks and would serve as building bloeks 
for the final model. The simulated results for the model will not be presented here, as 
they do not mean anything in this isolated eontext. 

6, Coordination Requirements 

VDT provides a tool to model eoordination among positions in the form of 
oommunieation links. Setting the values of Information Exehange Probability speeifies 
the severity of eoordination required. The higher the value, the higher is the eoordination 
required. No independent model was developed to model this behavior. However, as 
depieted in Figure 5.12 and explained in Seetion 5.3.5 above, eommunieation li nks will 
be plaeed between parallel tasks and realistie values set for the Information Exehange 
Probability to model eoordination requirements in the final model. 

7, Geography (Geography.vpm) 

Geography is one of the most important eonsiderations in DDD. Platforms and 
assets ean exeeute tasks only within their range of operations (e.g., a earrier ean operate 
aireraft or launeh missiles against targets only within its area of operations). Also, a SOF 
unit deployed in a partieular region eannot undertake tasks in some other region. To do 
that, the units will have to be redeployed to the new region at the expense of time. One 
more important eonsideration is the timing of asset deployment to tasks (i.e., two missiles 
launehed at a target from geographieally different platforms at the same time would take 
different amounts of time to reaeh the target). There is also a window of operation 
limitation within the DDD that is related to the geography (i.e., the seeond missile has to 
reaeh the target within a eertain time period of the first in order to eompletely destroy the 
target). 
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VDT does not offer a readymade solution to this problem. In VDT, models are 
representative of a process and the physical layout of positions and tasks themselves are 
not important. The project team tried various workarounds but we were not successful in 
modeling this aspect of DDD simulation. There were many different approaches 
attempted and it is not possible to include all of them here. One such attempt is presented 
below. As noted above, all models are placed as an electronic attachment to this 
document. 



The above figure represents an attempt to replicate geography in VDT. The model 
consists of one main objective - to destroy the SAM site. There are two positions 
deployed in different geographical locations, capable of doing the job. The SAM has a 
work volume of one day and will be destroyed by the first missile to hit it, i.e., when any 
of the positions execute it. Tasks 1 and 2 have been introduced to include an element of 
delay in the process and have been placed as a prerequisite for destroying SAM. Task 1 
has a work volume of 15 units and Task 2 has a work volume of 10 units. This delay 
would suggest that a missile launched by CVN would take 15 units of time to reach SAM 
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while it would take 10 units when launehed from DDGA. Both positions CVN and 
DDGA have a FTE of one. Simulated result of the above model is shown in Figure 5.14. 



Milestone Name 

Planned Date 

CPM Date 

Compaie Date 

Ciiticality 

2004 


Task Name 

Start 

Finish 

Float 

Criticality 


Meeting Name 

Start Date 

Meeting Risk 

interval 

# Meetings 

Feb |Mar |Apr 


Stall 

0220 04 

1 

♦ 


Projecti 

02/20/04 

03/15/04 

03/15/04 

1 



Stait 

02 20 04 

1 

♦ 


Task2 

02/20/04 

03/05/04 

03/12/04 

0 



Taski 

02/20/04 

03/12/04 

03/12/04 

1 



SAM Strike 

03/12/04 

03/15/04 

03/15/04 

1 

1 


Finish 

02 20 04 

1 

♦ 


Finish 

0220 04 

1 

♦ 

Pio(ji<im G.uitt; Pio(ji<im 



Figure 5.14 - Gantt chart for Geography 


We can observe from the above figure that the task SAM is held up until both 
Tasks 1 and 2 are finished. According to our assumptions, it should have been executed 
immediately after completion of Task 2 but was not so. This would mean that if two 
missiles are fired at the target then the target would be destroyed only when both the 
missiles reach it. This is different from DDD wherein even if one weapon reaches the 
target we get a partial success. In VDT we were not able to achieve partial success. As 
can be seen above, the target would be destroyed only when all weapons (assets) reach 
the target Thus, this approach was not implementable in our final product. 


8, Departments and Staffing (Expendable.vpm, Case - ‘higher level’) 

An important result of DDD experiments pertains to behavioral differences 
between congruent and incongruent organizational structures and task structures. This 
was to be attempted in VDT models by creating two types of organizations, namely 
Functional and Divisional, and two types of mission task structures, namely those 
expected to favor either the functional or divisional organization. The team realized that 
to capture the unique behaviors represented by these structures, the models would have to 
be built at a higher organizational level than shown and described above for expendable 
assets (Section V.C.l). If each position were to represent just one asset, there would not 
be a major difference in behavior between the performances of Functional organization 
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versus the Divisional organization (See the comparison between a functional and a lower 
level divisional model in Section V.F.12). This is because our project aims to model 
decision making regarding task assignments by the positions and this cannot be done if 
the positions represent just one asset each. 

The basic idea is the same as presented in Section V.C.l, but positions now 
represent platforms (with multiple assets) instead of the individual/single assets. Three 
departments were defined containing thirty persons (ten each) and the positions were 
staffed with persons from the departments. The model is shown in Fig 5.15. 



The above figure looks exactly like Fig. 5.1. Flowever, the difference lies in the 
properties of tasks, positions and meetings. The new parameters are shown in figures 
5.16, 5.17 and 5.18. 
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Figure 5.16 - Task parameters for the model in Fig 5.15 


All the task properties have remained the same except the work value. This 
property has been increased by a factor of ten to take into account the increased position 
FTE, which has been increased to reflect multi asset staffing. 



Figure 5.17 - Meeting participant’s parameters for model in Fig 5.15 

The meeting parameters have essentially remain the same. The only difference 
lies in the meeting allocation property. Since there are ten actors in every position, we 
wanted only one of them to attend the meetings so that the others are still available for 
the remaining tasks. Thus a meeting allocation of 10 percent has been defined that should 
theoretically restrict the attendance to the sub team leader. 
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[Table View 


^ Position Name 

Description | Department 

Application Experience 

FTE 

Salary 

Chart Color 
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1 
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Figure 5.18 - Person list for model in Fig 5.15 

Creation of departments and staffing is a new element in this model. Three 
departments have been created, each staffed with ten people as can be seen from Figure 
5.18. All these actors have generic skills and are well suited to undertake any of the three 
tasks. All actors from Department 1 are staffed in Position 1 and so on. 

In short, three major differences can be observed from the model in Fig 5.1. First, 
three departments have been created, one for each position, each containing ten persons. 
Positions have been staffed from their respective departments. FTE’s for positions and 
task durations both have been increased by a factor of ten. A meeting participation 
allocation has been defined at ten percent, such that after completion of Task 1, only the 
team leader from Position 1 should attend the meeting and the rest can continue with 
other tasks. Our assumption is that the simulated results of the two scenarios (Figures 5.1 
and 5.15) should exhibit similar results. The simulated results for the above model are 
shown below; 
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Figure 5.19 - Gantt chart for model in Fig 5.15 


Figure 5.19 displays the Gantt chart for the model illustrated in Figure 5.15. The 
project team members observed an unexpected behavior. According to our assumptions, 
the task durations should ideally have been close to the ones observed in Figure 5.4 but 
was not so. In Figure 5.19, the tasks seem to take much longer to complete. Moreover, 
Tasks 2 and 3 take much longer than Task 1 and even surpass the meeting duration, 
which was set at 200 days. To further analyze the problem, we compare the project 
statistics between the two models (Figure 5.1 and Figure 5.15) in Table 5.1. 


Case 

Lower Level 

Higher level 

Simulated Duration (days) 

Fig 5.1 53 

Fig 5.15 530 

CPM Duration (days) 

58 

580 

Simulated Start Date 

2/20/2004 

2/20/2004 

Simulated Finish Date 

5/10/2004 

5/12/2006 

Total Volume 

346.0 days 

7707.5 days 

Work Volume 

58.0 days 

4987.5 days 

Rework Volume 

0.0 days 

0.0 days 

Coordination Volume 

288.0 days 

2720.0 days 

Decision Wait Volume 

0.0 days 

0.0 days 

Coordination Risk 

0.093 

0.107 

Communications Risk 

0 

0 

Meeting Risk 

0.28 

0.32 

Percent Staffing 

0 

333 


Table 5.1 - Project statistics comparison 


Table 5.1 exhibits an anomalous behavior that the project team was not able to 
explain in the absence of any knowledge regarding the internal behaviors programmed 
into VDT. Note the coordination volume. It has jumped sharply in the higher level model 
to 2720 days. Also, because of this high coordination required, task durations have 
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increased drastieally; as ean be seen from Fig 5.19 above, Tasks 2 and 3 extend beyond 
Meetings 1 and 2. It seems that until the time meetings are in progress, all the work is 
stopped and then resumes after the meeting is over. This finding disconfirmed our 
assumption that the work would eontinue while one of the ten members was attending the 
meeting. 

D, MODELING SUCCESSES AND LIMITATIONS 

The team aehieved partial suceess in attempting to model individual behaviors. 
While some of the behaviors sueh as task preeedence, eoordination requirements and 
department and staffing eould be modeled sueeessfully, others sueh as geography, 
expendable assets and task prioritization were unsuecessful. Workarounds were 
developed for two of the unsueeessful attempts (Time eritieality of tasks and Geography). 

Time eritieality of tasks was to be aehieved by placing high priority critical tasks 
within the overall task strueture in aeeordanee with the DDD framework sueh that they 
would be made prerequisite for condueting other normal tasks. The aetors will have to 
expend resourees in executing these tasks and therefore will be eonstrained in their 
normal tasks. One differenee that remains is that while in DDD, the actors may chose not 
to destroy a SAM site in order to assign searee resources elsewhere, in VDT, onee 
modeled, the task will be executed. 

Geography was to be simulated by assigning tasks to aetors within their 
geographieal regions in aoeordanee with the DDD seenarios. Thus, while an aetor may 
have the skill to undertake all the tasks, he/she will be assigned to only those tasks that lie 
within his/her region of influenee. 

To further our learning and modeling, the project team deeided to proeeed with 
building a best effort representative model for DDD within the eonstraints of VDT. We 
wanted to observe the dynamies of a eomplex model after all the projeeted solutions in 
Seetion V.C were ineluded. Also, the team felt that it would be easier to identify and 
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isolate behaviors assoeiated with VDT that are identieal or in contrast with DDD, given 
the overall perspective of a complex task structure. 


E. BUILDING DDD REPRESENTATIVE MODEL 

To address the most important DDD scenarios and task structures, four models 
were built within VDT. These four models represent the functional (f) and divisional (d) 
task scenarios each being executed by a functional (F) and a divisional (D) organization 
structure. Further details of these scenarios within DDD are available in Section IFF. 
These models have been included as an electronic file ‘Final Model.vpm’, where each 
scenario is represented by a case within the model. 

The first task was to create a task structure based on DDD (refer to Figure 2.5). 
Complex tasks in the divisional task structure (d) were broken down into simple tasks as 
discussed in Section V.C.5 above. Targets (task sets) were placed in parallel/sequential 
depending upon their respective positions within the DDD framework. A task requiring 
one asset to complete (destroy) it was assigned a work volume of 1 day. Skill requirement 
was determined depending upon the assets required by a given task. All other properties 
were left as default. 

Six departments were defined each representing a major platform, namely the 
CVN, the three DDG’s, FFG and the CG. These departments were staffed with assets 
(sub platforms/ weapons in DDD) as per allocation within DDD (Figure 2.6). The 
departmental structure is presented in Figure 5.20. 
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Figure 5.20 - Staffing of personnel (assets) within departments. 


Within the project window, six positions were defined each representing a human 
player in the DDD experiment. The nature of staffing of these positions would determine 
the organizational structure (F or D). In the functional organization all similarly skilled 
assets were allocated to one position. For example, the strike commander position was 
staffed with all strike assets from all departments and he was responsible for all strike 
related tasks. In the divisional organization each position was staffed with assets from a 
single department. For example, the CVN commander had all assets from the CVN 
department. These were multiple capability assets, and the commander was responsible 
for tasks within his/her region of influence. This difference in staffing can be seen from 
Figure 5.21. 
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TLAM-2 
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TLAM-3 
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TLAM-5 

1 


Strike 

Functional Organization 


«ADD 


Figure 5.21 - Position staffing in the two scenarios 


Due to our inability in modeling geography in VDT, the project team along with 
faculty advisors manually determined the tasks lying within a position’s sphere of 
influence. For example, DDGA was tasked with targets in the western sector (ABW and 
NBW) since it was stationed in that sector in DDD (See Figure 2.4 in Chapter II). 


One major problem was modeling task structures such as defensive and random 
tasks like SAM’s. Within DDD, these are hidden from the players and only when an 
aircraft comes within its range (unknowingly), the SAM ‘appears’. The player has to then 
redirect assets in order to destroy this SAM site before attempting primary targets (e.g., 
ABW and NBE). The project team decided to place five similar tasks (SAM) in sequence. 
These tasks would commence immediately after start and would be placed independent of 
the primary task structure. However, some of these tasks (exact number depending upon 
their placement in DDD) would be made prerequisite for undertaking primary tasks. 


Communication li nk s were placed between a set of parallel tasks. This was done 
in order to enforce coordination among the actors (players) responsible for the task. A 
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value of 0.3, 0.1 and 0.1 was set for Information exehange probability, Noise probability 
and Functional error probability respectively. These values were set based on 
recommended and common levels in SimVision™ Users Guide (pages 85 - 89). 


A skill set was defined that contained various skills required by the actors and is 
presented in Figure 5.22. 



Figure 5.22 - Defined Skill set 


Assets were assigned skills based on their role. For example, F-18S aircrafts has 
two skills ‘AirStrike’ and ‘Strike’ while TLAM’s have only ‘Strike’. This differentiates 
between tasks that can be undertaken only by aircrafts and not by missiles. 


1, Divisional Organization and Divisional Task Structure - Case 
‘Divisional - Div’ 


A divisional organization was created by staffing positions from their respective 
departments (platforms). The six commanders (CVN, DDGA, DDGB, DDGC, FFG, and 
CG) were staffed with all actors from their equivalent departments (CVN, three DDG’s, 
FFG and CG). Thus each position contained multiple assets of varying skills. Tasks were 
assigned to positions keeping in mind their geographical positioning within DDD. For 
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example, DDGC was assigned primary responsibility for tasks in the eastern sector (ABE 
and NBE). Other positions in the sector provided secondary or support mission to it. The 
relevant model is shown in Eigure 5.23. 



Figure 5.23 - Divisional - Divisional scenario (Congruent) 

Note the structure of tasks in the figure above. They follow the task structure 
within DDD (Figure 2.5). However, there are differences. Two of the SAM (tasks) needs 
to be destroyed (completed) before attempting to destroy Bridge. Similarly, Mine 1 needs 
to be cleared before destroying NBE. 

The simulated results of the above model are presented in section V.E.3. 
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Functional Organization and Divisional Task Structure- Case 
‘Functional -Div’ 


The model for a functional organizational structure (F) with a divisional task 
structure (d) is shown in Figure 5.24. 



Figure 5.24 - Functional - Divisional scenario (incongruent) 

The major difference between this scenario as compared to the one in Figure 5.23 
is in the nature of staffing and task assignments. In this scenario, the six positions 
represent the functional commanders Strike, BMD, ISR, AWC, SUWC and SOF. The 
Strike commander is responsible for all strike related tasks, spread over the entire task 
structure. Other commanders are similarly responsible for their own set of tasks. This is 
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unlike the eongruent seenario (D-d) where the positions are responsible for tasks that lay 
within their sphere of influenee (e.g., CVN eommander was primarily responsible for 
Mine 1 and SAM 4 and provided support for all tasks in the eastern sector). This scenario 
(F-d) was designed in such a way that two or more positions (players) would be required 
to coordinate for completion of a task. For example, destruction of a SAM site requires 
coordination between the Strike commander and the SOF commander. 


3, Comparison of Simulated Results 

DDD Experiment 8 hypotheses that performance in the congruent (D-d) structure 
will be better than the incongruent structure (F-d). This is because in D-d tasks fall 
mostly under responsibility of one commander/position. In contrast, in F-d, tasks require 
assets across positions. 


A comparison of the simulated results from the above two scenarios is shown 
below. The congruent scenario (d-D) is represented by the dark boxes, and the 
incongruent scenario (f-D) is represented by the hashed boxes. For each measure of 
interest, the dark box plots immediately above the hashed one. 


Program Summary Statistics 

Case: Divisional-Div (Compare to: Functionai-Div) 

Program: Program 

Duration (10.4 ±1.5 days) — 

(8.2 ±0.6 days)- 

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12 12.5 

Total Revenues (0 ±0.0) — 

(0 ± 0 . 0 )- 
Total Costs (0 ±0 -0)- 
(0 ± 0 . 0 )- 

Non Labor Cost (k)(0 ±0.0)- 
(0 ± 0 . 0 )- 
Total Work Cost (0 ±0.0)- 

(0 ± 0 . 0 )-_ 

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 

Process Quality Risk (0.48 ±0.027) 

(0.37 ±0.034) 

Product Quality Risk (0.25 ±0.018) 

(0 .17 ±0 .021) 

Project Risk Index (0.00 ±0.000) 

( 0.00 ± 0 . 000 ) 

Functional Risk Index (0.49 ±0.036) 

(0.35 ±0.043) 

Communication Risk (0.59 ±0.019) 

(0.56 ±0 .031) 

Meeting Risk (0.00 ±0.000) 

(0 .00 ±0 . 000 ) 

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 




I Standard Deviation 


Figure 5.25 - Simulated result comparison between the scenarios 
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As can be observed from Figure 5.25, the results were exaetly opposite to the 
assumptions based on Experiment 8. The ineongruent seenario (F-d) seems to be more 
effieient than the eongruent seenario (D-d) in all respects. This outcome is contrary to the 
results obtained from A2C2 experiments, in partieular Experiment 8 (Seetion IFF). 


In view of the contrary results obtained above, the project team began the task of 
identifying the causes of differences. A detailed task wise comparison is shown below. 
The congruent scenario (D-d) is represented by the dark boxes and the ineongruent 
seenario (F-d) is represented by the hashed boxes. 



Figure 5.26 - Detailed task wise comparison between scenarios 


As can be observed from Figure 5.26, the ineongruent scenario (F-d) fares better 
at performing almost all of the tasks. The work volume is the same in both structures. 
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which is expected, sinee both task struetures defining the seenarios are identieal. The 
rework volume is miniseule and may be negleeted. However, the major differenee is in 
the eoordination and deeision wait volumes. The above figure shows that eoordination 
requirements and deeision wait times are mueh higher in the divisional organization than 
in the funetional organization. This is exaetly opposite to our assumptions given that the 
task strueture was designed to favor the divisional organization over the funetional 
organization. 

F. SIMPLE REPRESENTATIVE MODELS 

Subsequent to the unexpeeted behaviors from the above models, the team deeided 
that building further seenarios without resolving this issue was not warranted. Our 
approaeh then was to try and understand the behavioral nuanees of the two seenarios by 
building simple representative models and studying them. These models were developed 
in an ineremental fashion sueh that at every step we were able to either identify a 
partieular behavior or isolate it in the eontext of our projeet. These models are ineluded in 
the eleetronie attaehment as ‘A2C2 department behavior test.vpm’. 

To study various behaviors and to rule out effeets due to faetors sueh as 
eommunieation links the team set out to build models starting from a simple model of 
one position with two tasks where one task was suited to the skill of the position and the 
other was not. The aim was to see whether the ineompatible behaviors observed between 
the funetional and divisional seenario in Figures 5.23 and 5.24 eould be replieated in 
relatively simpler representation. 

1, Simple Model with One Position and Two Tasks 

The first model (Case ‘Baseline’) eonsisted of one position with an FTE of one 
having Skill A. The position was responsible for two sequential tasks A and B (both with 
a work volume of 50 days). While Task A required Skill A (mateh with the position). 
Task B required Skill B (mismateh with the position). As expeeted, the results showed 
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that completion of Task B requires more time than Task A (157 days as eompared to 71.2 
days). We ehanged the skill of the position to Skill B with the same task strueture (Case 
‘Skill B Responsibility’). In this ease the results were similar though Task A now 
required more time than task B (151.1 days as eompared to 74 days). We also 
experimented with assigning both skills A and B to the position (Case ‘S A& B’) to 
observe the differenee. As expeeted, both tasks require similar amount of time (71.3 days 
and 73 days). 

2, Simple Model with Two Positions and Two Tasks 

The seeond step involved adding one more position (Position B) with an FTE of 
one having Skill B. While Task A was assigned to Position A, Task B was assigned to 
Position B. We expeeted to see similar results between this model (Case ‘SA SB’) and 
the one in seetion 5.6.1 sinee the tasks were sequential. The results matehed our 
predietions in that Task A took 71.2 days and Task B took 72.9 days. 

3, Communication Link 

The next step involved adding eommunieation link between the tasks (Case ‘SA 
SB + eomm’) with an Information exehange probability of 0.3, Noise error probability of 
0.1, Funetional error probability of 0.1 and Projeet error probability of 0.1. We felt that 
adding a eommunieation link would inerease the eoordination requirement and thus the 
total workload but this was not so. The results indieate no appreeiable ehange as 
eompared to the model in Seetion V.F.2 (71.3 days for Task A and 72.9 days for Task B). 
We also tried the above eonfigurations with parallel tasks (Case ‘+ eoneur’ and ‘+eoneur 
eomm’) and obtained similar results. 

4, Increased FTE and Work Volume 

The next step was to proportionally inerease the FTE’s and the work volume by a 
faetor of ten (Case ‘+eoneur x 10’). We wanted to see whether inereasing the workload 
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causes any changes with the system. The results (74 days for each task) showed that there 
was no appreciable change. This was expected since even the FTEs had been increased 
proportionally. 


5. Adding Organizational Hierarchy 

We wanted to study behavior changes caused by organizational hierarchy (Case 
‘+con/con x 10 + boss’). To model this we added a sub team leader on top of the two 
Subteams (Positions A and B). We felt that vertical growth of organization would 
increase the workload due to increased coordination and decision wait times. However 
we found the results (74.1 and 74.2 days respectively) to be similar to those in Section 
V.F.4 above thus indicating that minor changes in organizational hierarchy alone do not 
cause appreciable changes in the amount of time required to complete tasks. 

6. Departments and Staffing 

We also wanted to study the behavior change due to introduction of departments 
and staffing (Case ‘+ org’). For this we created two departments, A and B, and staffed 
them with ten people each. People in department A had skill A, while people in 
department B had skill B. Positions A and B were staffed with ten people from 
departments A and B respectively. The results (70.3 days and 74 days) were same as the 
model in Section V.F.4 before. This indicated that there is no appreciable difference in 
performance between the two scenarios; one in which the unstaffed position has 10 
FTF’s and the other in which the position was staffed with 10 people. 

7. Building representative models for Functional and Divisional 

Scenarios 

We could establish from the models that, factors such as communication links, 
organizational hierarchy and staffing does not cause appreciable changes in project 
performance times. In this light, the team proceeded to model simple representative 
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scenarios for the functional and divisional organizations in Figures 5.23 and 5.24. For this 
the team built four models. Three of them deal with different versions of a divisional 
organization and one with the functional organization model. The task structure is 
common across all four models. 

The task strueture basically consists of four individual tasks divided into two sets 
of two tasks each (Figure 5.27). There are two skills defined (Skill A and B) common to 
all the models. Of the two tasks in eaeh set, one requires Skill A and the other Skill B. 
Eaeh task has a work volume of 500 days. All the tasks are arranged in parallel and the 
tasks within eaeh set are eonnected via communieation links. The Information exehange 
probability has been set at 0.3, Noise error probability at 0.1, Functional error probability 
at 0.1 and Project error probability at 0.1. These are reeommended and common values as 
per SimVision™ User Guide (pages 85 - 89). 

There are two independent positions with a defined FTE of 10 (except in one 
scenario, Seetion V.E.l 1). The nature of staffing of these positions will determine the 
structure of the organization as well as provide us with inputs that are relevant to study 
the various aspects of organizational behavior. 

There are two departments, 1 and 2. Each department is staffed with 10 people. 

Of the total 20 people, 10 have Skill A, and the rest have Skill B. The four models are 
discussed in detail below. Simulated results from all the models are discussed in Seetion 
V.E.12. 


8, Divisional Organization (Case ‘divisional’) 

In this scenario (Eigure 5.27), Department 1 contains all ten people having Skill 
A, and Department B has all ten people with Skill B. Position 1 is staffed with five 
people from Department 1 (Skill A) and five people from Department 2 (Skill B). 
Position 2 is staffed with rest of the ten people (five eaeh of both skills). Position 1 is 
tasked with Tasks 1 (Skill A) and 2 (Skill B) while Position 2 is tasked with Tasks 3 
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(Skill A) and 4 (Skill B). This organization thus represents two multi funetional positions 
each that should be fully capable to meet the requirements of the two tasks assigned. This 
is a congruent divisional model (D-d). 



Figure 5.27 - Divisional scenario 


The department organization and staffing is shown below. 
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Figure 5.28 - Department organization; Divisional structure 
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Ten persons (Persons 1 to 10) belong in Department 1 and have Skill A while the 
other ten (Persons 1-2 to 10-2) belong to Department 2 and have Skill B. Positional 
staffing of these people can be seen in Figure 5.29. 
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Figure 5.29 - Positional staffing in divisional structure 


9, Functional Organization (Case ‘functional’) 

In this scenario (Figure 5.30), the departmental organization is same as in Section 
V.F.8. The difference lies in staffing of people. Position 1 is staffed with all ten people 
from Department 1 (Skill A) and is responsible for tasks 1A and 2A (both requiring Skill 
A). Position 2 is staffed with all ten people from Department 2 (Skill B) and is 
responsible for tasks IB and 2B. This structure is similar to the one we have developed in 
Figure 5.24 wherein each player (position) is responsible for all tasks related to his/her 
skill throughout the task structure. For example, we can assume that Position 1 here 
relates to the Strike Commander in Figure 5.24 and he/she is responsible for all the Strike 
related tasks (represented here by Skill A). 


In contrast with the model described in Section V.F.8 above, this represents an 
incongruent structure. The functional organization (single skill positions) requires 
coordination between positions to accomplish the simultaneous tasks. This required inter 
position coordination is hypothesized to generate increased workload based on greater 
information processing requirements (Galbraith and the results of DDD Experiment 8). 
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Figure 5.30 - Functional structure 


The positional staffing for this scenario is presented in Figure 5.31 below. 
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Figure 5.31 - Positional staffing in functional structure 


76 






















































10, Divisional Organization (Reversed Staffing) (Case ‘Divisional - 
reversed staffing’) 

While in the functional scenario, all ten people from each department were staffed 
in one position, in the divisional scenario it was divided between the positions with five 
people from each department staffing each position. One primary concern of the project 
team was whether this was affecting the outcome. Thus the team decided to create a 
divisional scenario where staffing would be identical to the one in the functional 
structure. 


In this structure. Department 1 is staffed with five people with Skill A and five 
people with Skill B. Department 2 is staffed with the other ten people (five each of Skill 
A and B) as can be seen in Figure 5.32. Position 1 is staffed with all ten people from 
Department 1 and Position 2 is staffed with all ten people from department 2. This model 
in comparison with that in Section V.F.8 has all staff for a position coming from one 
department. Thus, any increase in workload presumed by VDT because of 
interdepartmental staffing in Section V.F.8 should be eliminated here. The organizational 
and task structures are exactly the same as that in Figure 5.27. 



Figure 5.32 - Departmental staffing; Functional structure 
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The position staffing is shown in Figure 5.33. 
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Figure 5.33 - Positional staffing; Funetional structure 


After we simulated the above three scenarios we found considerable differences 
between the functional and the divisional structures. These are summarized in the table 
below. As a result of the differences, the team decided to build an additional structure 
where the decision making regarding allocation of resources would be taken out of the 
purview of the positions in the divisional models. 


11, Lower Level Divisional Organization (case ‘divisional - lower level’) 

In this model (Figure 5.34) the departmental and task structures are exactly the 
same as in Section V.F.8 (i.e., divisional organization). However, four new positions 
have been defined, two each below positions 1 and 2. These positions have been staffed 
with five people each. Position Skill A1 is staffed with 5 people of Skill A from 
Department 1 and is responsible for Task 1. Position Skill B1 is staffed with 5 people 
from Department 2 (Skill B) and is responsible for Task 2 (Figure 5.35). Positions Skill 
A2 and Skill B2 are similarly staffed with the remaining people from departments 1 and 2 
and are responsible for tasks 3 and 4 respectively. 

Defining the positions in this manner should eliminate the coordinated decision 
making required of the positions as in above models. Whereas, earlier, positions had to 
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decide whom to allocate for each task, that decision has already been made given this 


structure. 



Figure 5.34 - Lower level divisional structure 


The positional staffing is shown in Figure 5.35. 
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Figure 5.35 - Positional staffing; Lower level divisional structure 


The four positions have been staffed such that each position is responsible for one 
task and the skills of the position match the skills required to execute the task. 
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12, Summary and Comparison 


The simulated results from the four models are presented below in tabular 


form: 


Case 

Divisional 

Functional 

Divisional 
Reversed Staffing 

Divisional 

Lower level 

Task 1 

186.3 

140.3 

186.3 

144.2 

Task 2 

186.3 

140.3 

189.0 

144.2 

Task 3 

189.1 

141.0 

189.0 

144.0 

Task 4 

189.1 

141.1 

189.1 

144.1 


Table 5.2 - Task duration eomparison of the four seenarios 


From the above table it is elear that the funetional organization is better at 
performing the tasks as eompared to the two divisional scenarios. There is no appreciable 
difference in performance between the Divisional and the reversed staffed Divisional 
structures indicating that the nature of staffing alone does not affect the outcome. Another 
interesting observation was that the lower level divisional model was comparable in 
performance to the functional model. This would seem to indicate that the major reason 
for the poorer performance of divisional scenarios is the manner in which VDT assigns 
actors to tasks. In both the divisional scenarios, each position had ten people (five of each 
skill), and the position was expected to assign five people to each task depending upon 
the skill requirement. Detailed project statistics comparison of the models is shown in 
Table 5.3. 
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Case 

Simulated Duration 

Divisional 

Functional 

Divisional 
Reversed Staffing 

Divisional 

Lower level 

(Days) 

135.6 

101.4 

135.4 

104.2 

CPM Duration (Days) 

100 

100 

100 

100 

Total volume 

2024.4 days 

2013.2 days 

2023.5 days 

2037.5 days 

Work volume 

2000.0 days 

2000.0 days 

2000.0 days 

2000.0 days 

Rework volume 

18.8 days 

9.8 days 

17.7 days 

22.8 days 

Coordination volume 

5.4 days 

3.4 days 

5.7 days 

8.0 days 

Decision wait volume 

0.2 days 

0.1 days 

0.1 days 

6.7 days 

FRI 

0.497 

0.503 

0.537 

0.475 

PRI 

0 

0 

0 

0 

Coordination risk 

0.514 

0.513 

0.509 

0.386 

Communication risk 

0.77 

0.77 

0.77 

0.58 

Meeting risk 

0 

0 

0 

0 


Table 5.3 - Project properties comparison of the four scenarios 


The difference in performance between the functional and the lower level 
divisional model lies mainly in the rework, coordination and decision wait volumes. It 
seems that the more hierarchic organization (lower level divisional model) results in 
higher values for all of these thus degrading performances. But the same organization 
results in improving the coordination and communication risks. The absence of Project 
Risk Index (PRI) suggests that we were not able to capture the project level coordination 
and this may explain part of the discrepancy in results. However, due to paucity of time, 
we could not further experiment with the models and decided to document our findings. 


An explanation for these differences between Functional and Divisional lower 
level structures is not readily apparent and we leave further exploration of these questions 
to those who do follow up work on this effort. 
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VI. CONCLUSIONS 


This concluding chapter argues that VDT has great potential that can be exploited 
further to augment DDD experiments. Despite our moderate sueeess in fully replieating 
many of the DDD/Experiment 8 eontextual behaviors, we have shown how these ean be 
studied further using a “building bloeks” approaeh - starting with simple models to 
isolate the relevant behaviors, and then integrating those within a more eomprehensive 
seenario and more complex organization struetures. We deseribe how this projeet 
eontributes to our knowledge in eomputational simulation systems and their possible 
applieations to A2C2 experiments. We also diseuss some limitations of this work and 
natural extensions for future work. 

A, SUMMARY OF PROJECT RESULTS 

In this study we present evidence that eomputational simulation systems (i.e., 
VDT) ean be used to emulate experiment results. It is only the paueity of time that 
prevents us from going further with the models and eapturing other relevant DDD 
variables (e.g. the project level coordination). However, by doeumenting our findings, we 
leave the door open for future teams that may want to expand upon this work. 

1. Usefulness of Computational Simulation 

Beeause organizational experimentation in the field is eostly and time-consuming, 
and because eontrolled experiments in the laboratory are diffieult to run as provide data 
based on small sample sizes, organizational simulation is a eompelling method for 
understanding many kinds of real-world behavior. 

It ean be a powerful tool for generating and filtering testable hypotheses to be 
further evaluated in field and laboratory experiments. Furthermore, it ean provide insight 
into what experimental data would be important to eolleet. With all these eonsiderations 


83 



in mind, and given the observed capability of using VDT to model DDD, our team 
considers this project worth the effort of undertaking it. 

2. Context 

Organization theory describes the concept of “organizational congruence” as a 
factor influencing organization effectiveness. This has been demonstrated by recent 
results from C2 experiments that have shown that ""the better an organization is matched 
structurally to the overall mission, the better will that organization perform - and that 
mismatches are potential drivers for adaptation of organization structure” (Diedrich et 
ah, 2003). 

The results of Experiment 8 (Kleinman et ah, 2003), clearly show that 
performance - broadly defined as the percentage of tasks completed - was significantly 
higher in the congruent cases (fit between organization and mission) compared with 
incongruent cases (misfit between organization and mission). 

Our primary goal in this project was to determine if and how we could use VDT 
to emulate the results obtained from A2C2 Experiment 8. This required adapting the 
VDT tool to the domain of military command and control. 

3. Strategies and Results 

Starting with a core of DDD contextual micro-behaviors derived from lab 
observations, we use a building-blocks strategy in our attempt to capture those key 
behaviors with VDT. In Chapter 5 we describe the 8 selected DDD behaviors, the 
solutions adopted to model them, and some limitations. 

While the team was successful in modeling behaviors such as task precedence, 
coordination requirements and department and staffing, for others such as geography, 
expendable assets, the impact of coordination or workload, and task prioritization the 
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results were not as expeeted. And although we found solutions for two of these initial 
anomalies (time eritieality of tasks and geography), some limitations still applied. In the 
ease of time criticality of tasks the proposed solution was to use the ‘high priority task 
switeh’ available in VDT eonstraining the aetors to expend resourees in exeeuting these 
priority tasks first. However, this solution eould not eapture the option that aetors have in 
DDD to skip one of these erhieal tasks; in VDT, onee modeled, the task will be exeeuted. 

For geography the solution adopted was to assign tasks to aetors within their 
geographieal regions in aoeordanee with the DDD seenarios, irrespeetive of their skills. 
One major limitation still exists here, beeause this solution does not aeeount for the time 
period required for an asset (roeket) to reaeh the assigned target. 

After modeling the seleeted individual behaviors and implementing all the 
solutions deseribed in seetion 5.3, we built two struetures D-d and F-d and eompared the 
simulated results. Our aim here was to observe the dynamies of a eomplex model after all 
the projeeted solutions in seetion 5.3 are ineluded. Also, we seek to identify and isolate 
behaviors assoeiated with VDT that are eonsistent or in eontrast with DDD. 

Our results show that eoordination requirements and deeision wait times are mueh 
higher in the divisional organization (eongruent with task seenario) than in the funetional 
organization (ineongruent with the task seenario). This is exaetly opposite to our 
assumptions that eongruent strueture/seenario should perform better. Therefore, we 
proeeeded to isolate and understand the behavioral nuanees of the two simulations by 
building simple representative models, developed in an ineremental fashion. The results 
indieate that faetors sueh as eommunieation links, organizational hierarehy and staffing 
do not have mueh explanatory power for the differenee between seenarios. This finding 
may have implieations for the ultimate sueeess of using VDT to eapture design prineiples 
used in DDD beeause the latter relies signifieantly on eoordination as a defining faetor of 
eongruenee and hierarehy plays a signifieant role in military organizations. Further 
exploration of these faetors is required. 
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The last step was to model four simple representative struetures (2 positions/four 
tasks) and to eompare the results. While the task scenario was kept the same across all 
four models, three different versions of a divisional organization and one of functional 
were built. The first divisional structure (divisional) involved mixed skills and staffing 
from two departments, the second divisional structure (reverse staffed divisional) used 
mixed skills but staffing from a single department while the last divisional structure 
(lower level divisional) was more hierarchical developed, introducing 2 sub-positions 
below each existing position. In the latter structure (lower level divisional) the task 
assignment was divided between the sub-positions, for each set of tasks. 

The results indicate that there is no appreciable difference in performance 
between the divisional and the reverse staffed divisional scenario, which leads to the 
conclusion that the nature of staffing alone does not affect the outcome. Also, as the 
lower level divisional model is comparable in performance to the functional model, we 
conclude that the major reason for the poor performance of divisional scenarios could be 
the manner in which VDT assigns actors to tasks. 

B, CONTRIBUTIONS 

We have shown that emulating organizational behavior using computational 
simulation models is a valuable strategy for generating insight into organizational 
contextual behavior. Our project contributes to a better understanding of the advantages 
and the possible limitations of such work, showing that the task of building 
computational models to replicate experiment results is not an easy one but also not 
impossible. Our work also clearly illustrates that VDT has great potential and that 
individual behaviors needed in the modeling and design process could be isolated and 
further examined. 
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c. 


WEAKNESSES 


Due to lack of time and challenges of modeling critical DDD behaviors with VDT, 
we cannot further, analyze and compare the results against the observed organizational 
performance during A2C2 Experiments. As a consequence, we limit our final work to 
analyzing and interpreting the VDT simulated results and to documenting the gains and 
limitations of our work. Hopefully this will assist people pursuing this topic in the future 
and provide more in-depth examination of how VDT can be used as a pre-experimental 
modeling tool for A2C2 research. 

D, CONCLUDING REMARKS 

Contextually changing behavior is a common phenomenon in military 
organizations, and the structural match of an organization to the overall mission leads to 
better performance. 

Also the mismatches are potential drivers for adaptation (Diedrich et al., 2003). 
Experiments using simulation models have yielded insights into the magnitude and 
direction of certain contextual effects. Still, much research into contextual behavior 
remains to be done, both theoretically and empirically, and VDT can be a viable tool to 
this goal. 
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